'null' check before property access

[h2oche]

tc39/ecma262#2267 changes the behavior of object property access of specification, which seems to be incorrect when compared to other JS engines.

Related Issues

• Is null[{ toString: () => { console.log('hit') } }] supposed to hit the console.log? tc39/ecma262#2659
• Incorrect tests after change to evaluation order for member assignment tc39/test262#3407

Related tests (# of tests = 35)

• test/language/expressions/compound-assignment/S11.13.2_A7.10_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.10_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.11_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.11_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.1_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.1_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.2_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.2_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.3_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.3_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.4_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.4_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.5_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.5_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.6_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.6_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.7_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.7_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.8_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.8_T2.js
• test/language/expressions/compound-assignment/S11.13.2_A7.9_T1.js
• test/language/expressions/compound-assignment/S11.13.2_A7.9_T2.js
• test/language/expressions/logical-assignment/lgcl-and-assignment-operator-lhs-before-rhs.js
• test/language/expressions/logical-assignment/lgcl-nullish-assignment-operator-lhs-before-rhs.js
• test/language/expressions/logical-assignment/lgcl-or-assignment-operator-lhs-before-rhs.js
• test/language/expressions/postfix-decrement/S11.3.2_A6_T1.js
• test/language/expressions/postfix-decrement/S11.3.2_A6_T2.js
• test/language/expressions/postfix-increment/S11.3.1_A6_T1.js
• test/language/expressions/postfix-increment/S11.3.1_A6_T2.js
• test/language/expressions/prefix-decrement/S11.4.5_A6_T1.js
• test/language/expressions/prefix-decrement/S11.4.5_A6_T2.js
• test/language/expressions/prefix-increment/S11.4.4_A6_T1.js
• test/language/expressions/prefix-increment/S11.4.4_A6_T2.js
• language/expressions/assignment/target-member-computed-reference-null.js
• language/expressions/assignment/target-member-computed-reference-undefined.js

New Task

• Open a new issue or send a pull request

[jhnaldo]

I checked this problem is now solved in the latest ECMA-262 and Test262. However, this problem seems still not been resolved:

$ esmeta test262-test -extract:target=e30935d -test262-test:target=dc1dc28aa4 tests/test262/test/language/expressions/compound-assignment/S11.13.2_A7.10_T1.js -silent
# [InterpreterError] return not undefined: comp[~throw~](#2720)

I think we should open a new issue or send a pull request to resolve this problem.

[jhnaldo]

While this issue was related to tc39/test262#4060, the recent version of ESMeta resolves this issue by following the new evaluation order of property key resolutions.