-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect tests after change to evaluation order for member assignment #3407
Comments
cc @Ms2ger @romulocintra @sarahghp @ryzokuken @ptomato Is this something any of you want to tackle? |
We can also observe this behavior with our implementation ESMeta, which strictly follows the spec. Currently, spec and tests are diverged. Additionally, following tests also seems to be related to this issue by: |
Related to this issue, I believe the following tests are also incorrect according to the current spec text:
Namely, the test expects that at L49: |
I suppose tc39/ecma262#3307 fixes this issue as well, but needs to be confirmed. |
tc39/ecma262#2267 changed the sequencing of the
RequireObjectCoercible
-on-base /ToString
-on-property for member assignments, likea[b] = c
. Some of the tests for the old behavior were updated, and new tests were added, in #2993. But that PR seems to have only covered plain=
-style assignment, and there's still some tests which assert the previous behavior for compound assignment and increment/decrement. By reading these should all have been updated as well.Specifically, the
RequireObjectCoercible
happens only during the eventualGetValue
on the LHS, which happens in, for example,AssignmentExpression : LeftHandSideExpression AssignmentOperator AssignmentExpression
UpdateExpression : LeftHandSideExpression ++
.By that point the
ToString
has already happened,ToPropertyKey
callEvaluatePropertyAccessWithExpressionKey
MemberExpression : MemberExpression [ Expression ]
.In fact, as I read the spec,
null[{ toString: () => { console.log('hit') } }]
is now supposed to printhit
before throwing (by exactly the same logic, except that theGetValue
call happens in the Evaluation semantics for ExpressionStatement, though of engines I have on hand only ChakraCore implements that behavior.I've also opened an issue on ecma262 to confirm my reading: tc39/ecma262#2659
Tests which seem to me to be in error include;
The text was updated successfully, but these errors were encountered: