fix(js): reject top-level import/export in scripts as a SyntaxError#88
Open
codymullins wants to merge 2 commits into
Open
fix(js): reject top-level import/export in scripts as a SyntaxError#88codymullins wants to merge 2 commits into
codymullins wants to merge 2 commits into
Conversation
Static ImportDeclaration and ExportDeclaration are module-only productions (spec sec-modules). In a script, which is the default goal, the parser accepted them and the compiler later threw an internal NotSupportedException, so a negative parse test saw the wrong failure (got NotSupportedException instead of a parse error). Guard the static import/export dispatch in ParseProgramStatement on the module goal. In a script a top-level import/export now throws a JsParseException, which the eval path surfaces as a JS SyntaxError. The import(...) and import.meta expression forms are unaffected (they route to ParseStatement before the guard). Test262 language/global-code 53.3% -> 58.7%, language/eval-code 86.6% -> 87.4% (+8 scenarios across both, the import/export parse tests). No regression: the new parse error fires on zero positive tests. The full-language headline is flat only because an unrelated batch of flaky async/dynamic-import tests in expressions/statements wobbled by the same magnitude this run.
The module-syntax parser tests parsed import/export through ParseProgram (the script goal), which now rejects them. Route those tests through the module goal where the productions are valid, and add tests that a top-level import/export in a script throws JsParseException while import(...) still parses. Two export-list tests declare their local bindings to satisfy the module-goal early-error pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What
Static
ImportDeclarationandExportDeclarationare module-only productions (aScriptBodyis just aStatementList). The parser accepted them in a script and the compiler later threw an internalNotSupportedException, so negative parse tests saw the wrong failure:Fix
Guard the static import/export dispatch in
ParseProgramStatementon the module goal (_module). In a script, a top-levelimport …/export …now throws aJsParseException— a parse-phase SyntaxError, which theevalpath surfaces to JS as aSyntaxError. Theimport(...)andimport.metaexpression forms are unaffected (they route toParseStatementbefore the guard).Result (Test262,
languagescope)language/global-codelanguage/eval-code+8 scenarios across the two categories (the
import/exportparse tests in each).Regression check
The new parse error fires on zero positive tests (grep of the full-language failure dump for the new message: 0 hits). The only behavior change is rejecting module syntax in a script, which was already a compile failure before. The full-language headline stays flat this run only because an unrelated batch of flaky async/
import(...)tests inexpressions/statementswobbled by ~the same count — a known run-to-run variance under the Debug harness, not caused by this change (a parser guard on theimport/exportstatement tokens cannot affect those expressions).