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

Early Error rules and covering grammars #2421

Open
jmdyck opened this issue Jun 1, 2021 · 0 comments · May be fixed by #3227
Open

Early Error rules and covering grammars #2421

jmdyck opened this issue Jun 1, 2021 · 0 comments · May be fixed by #3227
Labels

Comments

@jmdyck
Copy link
Collaborator

jmdyck commented Jun 1, 2021

Every Early Error (EE) rule of the form:

It is a Syntax Error if X is not covering a Y.

is accompanied by a rule of the form:

All Early Error rules for Y and its derived productions
also apply to the Y that is covered by X.

[As of the merge of PR #2604, these are now bundled into the definition of "must cover".]

But talking about the application of EE rules to the Y makes me wonder about the application of EE rules to the X.

The spec says very little on this topic. About the only thing I could find is in 13.2.5.1, where it says (roughly) that if an ObjectLiteral occurs in X, then don't apply a particular EE rule. (B.3.1 has similar wording.) This seems to imply that one should apply EE rules to X except where specifically told otherwise (as here).

But it seems to me that if X is (roughly speaking) a parsing hack, and Y represents the 'true' structure of the text (in the sense that it's the structure upon which the spec defines the semantics of the text), then you should never apply EE rules to the X, only the Y.

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)?

Or conversely, an example where applying EE rules to the X (other than where explicitly forbidden) finds a spurious error in a valid script (valid according to test262 or web reality, say).

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

Successfully merging a pull request may close this issue.

1 participant