Destructuring: Fix array unpacking assignments with holes on RHS #9412
Conversation
motiz88
force-pushed
the
fix-destructuring-assign-unpack-holes
branch
from
0ecb9ca
to
741b722
Compare
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9921/ |
1 similar comment
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9921/ |
existentialism
added
the
PR: Bug Fix 🐛
| var [a, b] = [, 2]; | ||
| [a, b] = [1, 2]; | ||
| [a, b] = [, 2]; | ||
| ; // Avoid completion record special case |
There was a problem hiding this comment.
Not in this PR, but this optimization is wrong: ; keeps the previous completion value:
eval("0;;;;")Can you use something like 0; instead?
There was a problem hiding this comment.
Yeah, I've just realised this on another PR. Ultimately it's a false negative in the isCompletionRecord check, which could be quite expensive to correct without memoising somehow.
I'll change this, but FWIW there are several other tests that currently use ; in this way and would need to change similarly.
There was a problem hiding this comment.
This can/should be handled in another PR
|
Thank you! |
…el#9412) This fixes an issue where destructuring assignments eligible for the "array unpacking" optimization would fail to compile when the array literal on the right-hand side of the expression contained holes. Example input: ```js [a, b] = [, 2]; ; // Avoid completion record special case ``` The error message was `Property right of AssignmentExpression expected node to be of a type ["Expression"] but instead got null`. Now the above code compiles to: ```js a = void 0; b = 2; ; ``` This PR also adds a couple of related test cases that were missing, to ensure the change doesn't regress them: * Normal assignment expression with unpacking * Declaration with unpacking and a hole on RHS
lock
bot
added
the
outdated
This fixes an issue where destructuring assignments eligible for the "array unpacking" optimization would fail to compile when the array literal on the right-hand side of the expression contained holes.
Example input:
The error message was
Property right of AssignmentExpression expected node to be of a type ["Expression"] but instead got null.Now the above code compiles to:
This PR also adds a couple of related test cases that were missing, to ensure the change doesn't regress them: