Skip to content
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

Editorial: Don't check a cover for early errors #3227

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jmdyck
Copy link
Collaborator

@jmdyck jmdyck commented Nov 22, 2023

Resolves #2421 (sort of).

Issue #2421 asks:

So can anyone give an example of where you actually need to apply EE rules to the X (the initial parse), to find an error that you wouldn't find by applying EE rules to only the Y (the thing that X covers)?

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.

  • Rather than only talking about applying EE rules to the covered node itself, there's also its descendants to consider.
  • But we can't say that all the descendants are EE-checked, because some might themselves be covering nodes.
  • And also, the term 'derived productions' is undefined.

commit 2:

In 13.2.5.1, the paragraph beginning

In addition to describing an actual object initializer the |ObjectLiteral| productions are also used as a cover grammar for |ObjectAssignmentPattern| ...

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

In certain contexts, |ObjectLiteral| is used as a cover grammar for a more restricted secondary grammar.

and that looked like a good place for the example.

spec.html Outdated
Comment on lines 18405 to 18414
<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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great explanation, but I still think it makes more sense under "Static Semantics: Early Errors" as in #3224.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think I'll add a commit to see how that could look.

@jmdyck
Copy link
Collaborator Author

jmdyck commented Nov 24, 2023

Added 2 fixups:


commit 3:
Move the early error rule for ObjectLiteral from the end of the section to the start.

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.
@jmdyck
Copy link
Collaborator Author

jmdyck commented May 23, 2024

(force-pushed to resolve merge conflicts from PR 3309)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Early Error rules and covering grammars
3 participants