Editorial: Don't check a cover for early errors #3227
Conversation
spec.html
Outdated
| <p>For example, consider:</p> | ||
| <pre><code class="javascript"> | ||
| let o = {f = 1}; | ||
| </code></pre> | ||
| <p>`{f = 1}` is parsed as an |ObjectLiteral| with a |CoverInitializedName|, which results in a Syntax Error via one of the early error rules in the next section.</p> | ||
| <p>In contrast, consider:</p> | ||
| <pre><code class="javascript"> | ||
| ({f = 1} = {f: 2}); | ||
| </code></pre> | ||
| <p>Here, `{f = 1}` is again initially parsed as an |ObjectLiteral| with a |CoverInitializedName|, but since it's the |LeftHandSideExpression| of an |AssignmentExpression|, it must cover an |AssignmentPattern|, so the |ObjectLiteral| and |CoverInitializedName| are not subject to early error rules. Instead, `{f = 1}` is reparsed as an |ObjectAssignmentPattern| with an |AssignmentProperty|, and there is no Syntax Error.</p> |
There was a problem hiding this comment.
This is a great explanation, but I still think it makes more sense under "Static Semantics: Early Errors" as in #3224.
There was a problem hiding this comment.
Yeah, I think I'll add a commit to see how that could look.
jmdyck
force-pushed
the
unchecked_covering_node
branch
from
9dc5ad6
to
5ddd859
Compare
|
Added 2 fixups: commit 3: Generally, when an 'Early Errors' section has multiple rules, it presents them so that their productions appear in more-or-less the same order as in the preceding 'Syntax' block. In the status quo, this section can't do that, because the ObjectLiteral rule has to appear after the para about "the following Early Error rules are not applied". But in this PR, that para is now gone, so the rule for ObjectLiteral can go to the top of the section. This has the nice side-effect of making the CoverInitializedName rule last in the section, where a long Note will fit better (i.e., the Note won't push normative parts of the section off-screen). commit 4: Bring together all the prose about ObjectLiteral being a cover for ObjectAssignmentPattern. (In the status quo, this comes up three separate times.) And expand it somewhat, to give the reader a bit more to latch onto. |
That is, if Parse Node _P_ must cover an _N_, no early error rules are applied to _P_ or any of its descendants.
In the section about early errors of ObjectLiterals, delete the paragraph about the non-application of some rules in some cases. But add a related example to the previous section.
…jectAssignmentPattern.
jmdyck
force-pushed
the
unchecked_covering_node
branch
from
5ddd859
to
8fa7cb3
Compare
|
(force-pushed to resolve merge conflicts from PR 3309) |
Resolves #2421 (sort of).
Issue #2421 asks:
This PR assumes that there is no such case, and is labelled "editorial" on that assumption.
commit 1:
This augments the definition of
_P_ must cover an _N_to say that no early error rules are applied to_P_or any of its descendants.This also prompts a rewording of the existing line that 'redirects' early error processing to the covered node.
commit 2:
In 13.2.5.1, the paragraph beginning
is, after commit 1, technically redundant. However, it seems to me that there's still some value in bringing up at least some of its ideas.
I thought about making it a Note and rephrasing it to say that this is as a particular example of the semantics of "must cover", but didn't make much progress. (I could try again if the editors want.)
Instead, it seems to me that what's really needed is an example of how an ObjectLiteral is EE-checked, depending on whether or not it's a covering node. I noticed that the previous section had a somewhat overlapping paragraph beginning
and that looked like a good place for the example.