Wrong evaluation order for keyed lookup |
|||||||||
Issue description
'language/expressions/assignment/S11.13.1_A7_T1': [FAIL],
'language/expressions/assignment/S11.13.1_A7_T2': [FAIL],
'language/expressions/assignment/S11.13.1_A7_T3': [FAIL],
One example:
assert.throws(TypeError, function() {
var base = null;
var prop = {
toString: function() {
$ERROR("property key evaluated");
}
};
var expr = function() {
$ERROR("right-hand side expression evaluated");
};
base[prop] = expr();
});
null is not a valid object so we should not do the ToName for prop
,
Jun 29 2015
Waiting for spec resolution
,
Jun 29 2015
Related: v8:4248
,
Mar 10 2016
Marking as 'Available' as PendingFurtherInfo makes it not open, but this is still an issue to resolve.
,
Mar 11 2016
,
Apr 7 2016
The conclusion from the most recent TC39 meeting is that the spec will remain as-is. SpiderMonkey is working to move to the specced behavior (which they already supported for increment/decrement, but not for compound assignment), which should give us a bit more confidence that no real code depends on this.
,
Jun 22 2016
,
Mar 23 2017
,
Mar 25 2017
,
Jun 14
For the record: the reason we fail this test is because we call "expr()" before throwing. "prop.toString()" is not called.
,
Jun 14
,
Jun 14
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by arv@chromium.org
, Jun 26 2015