Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it safe to move this into a note? These are currently normative requirements. Are they also described elsewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes—in Destructuring Assignment, |LeftHandSideExpression| is refined using |AssignmentPattern|, which uses |ObjectAssignmentPattern| in place of |ObjectLiteral| and |AssignmentProperty| in place of |PropertyDefinition| and therefore never even encounters the nonterminals to which the Early Error rules apply (and likewise for |CoverParenthesizedExpressionAndArrowParameterList| and |CoverCallExpressionAndAsyncArrowHead|).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For each of the productions:
the spec says:
Note that AssignmentPattern has 2 alternatives, ObjectAssignmentPattern and ArrayAssignmentPattern.
Given that
{
, and[
,it's clear that if LeftHandSideExpression is an ObjectLiteral, the covered AssignmentPattern must be an ObjectAssignmentPattern. So, somewhat loosely, we can say that ObjectLiteral production is a cover grammar for ObjectAssignmentPattern.
The wording of the subordinate clause is a bit odd, it means more like "When an |ObjectLiteral| appears in a context that requires it to cover an |ObjectAssignmentPattern|" (i.e., when it appears as the LeftHandSideExpression in instances of the productions listed above). In those cases, the above early error rule applies, and (roughly speaking) the ObjectLiteral is reparsed as an ObjectAssignmentPattern.
Here, "the following Early Error rules" are rules for PropertyDefinition and ObjectLiteral. Note that a PropertyDefinition can only appear in a PropertyDefinitionList, which can only appear in an ObjectLiteral.
So the quoted sentence is saying that, when an ObjectLiteral is reparsed as an ObjectAssignmentPattern, the rules for ObjectLiteral don't apply. Which makes sense: the ObjectLiteral isn't really an ObjectLiteral, it's just a parsing hack, so it would be weird to subject it to the static rules for ObjectLiterals.
But I don't think we actually say that elsewhere, so I don't think it's safe to move this to a Note.
This is basically the same idea: a CoverEtc will always be reparsed into something else, so if you've got a CoverEtc that happens to contain an ObjectLiteral, don't apply the ObjectLiteral EE rules (because it might not be an ObjectLiteral in the covered node).
But I don't think we say that elsewhere.
Personally, I'd much prefer if, in the definition of "P must cover an N", we also say (something like):
No Early Error rules are applied to _P_ or any of its descendant Parse Nodes.
See issue #2421.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be willing to include such a change in either this PR or #3223.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think such a change needs a dedicated PR, so I've created #3227.