ReviewOS

zig-utils/zig-js

Parser: retain module early-error diagnostics

#973
Closed chris opened this 9 days ago ·
9 days ago

Parent: #899

Problem

Nine module-only parser exits still discard JavaScriptCore's diagnostic reason. A WebKit module-parser oracle (JavaScriptCore 625.1.22) confirms these families:

sourceJavaScriptCore
var x; let x;Cannot declare a let variable twice: 'x'.
let x; var x;Cannot declare a var variable that shadows a let/const/class variable: 'x'.
import x from "a"; import x from "b";Cannot declare an imported binding name twice: 'x'.
let x; export {x}; export {x};Cannot export a duplicate name 'x'.
export default 1; export default 2;Only one 'default' export is allowed.
export {x};Exported binding 'x' needs to refer to a top-level declared variable.
import "m" with {type:"json",type:"json"};Unexpected identifier 'type'. A duplicate key for import attributes 'type'.
import "m" with {type: json};Unexpected identifier 'json'. Expected an attribute value.
export {"x"};Cannot use module export names if they reference variable names in the current module.
export {1};Unexpected number '1'. Expected a variable name or a module export name string for the export declaration.
export {"\uD800" as x} from "m";Unexpected string literal "\uD800". Expected a well-formed-unicode string for the module export name.
<!-- commentUnexpected token '<'

zig-js rejects the programs but currently surfaces UnexpectedToken for each. Import-name and exported-name positions use distinct JSC suffixes and must remain distinct.

Implementation shape

  • carry declaration-kind reasons through the existing module declaration inventory; use the current pattern shape only on collisions;
  • retain duplicate-export and unresolved-local names from the existing export inventory;
  • give ModuleExportName an explicit grammar context (imported, local export, exported name, import-attribute key);
  • retain the second import-attribute key/value token;
  • attach the already-recorded HTML-comment offset to the offending < or > token;
  • add no new accepted-program traversal or allocation.

Verification

  • exact WebKit/JSC module differential across declaration order, destructuring, imports, exports, attributes, malformed names, and HTML comments;
  • parser module diagnostic tests;
  • standalone parser module;
  • exact-parent test262 module comparison.
9 days ago

Completed in 78cc6a3c (fix(parser): diagnose module early errors (#973)).

Module declaration collisions, duplicate/default exports, unresolved local exports, import-attribute keys and values, ModuleExportName grammar contexts, malformed string export names, and both HTML-comment spellings now retain structured reasons, tokens, names, and offsets.

Verification:

  • WebKit/JSC 625.1.22 module differential: 37/37 exact messages.
  • Standalone parser module against current main's pinned zig-regex revision: 242/242 passed.
  • Exact-parent test262 comparison: test/language/module-code 599/599 and test/language/import/import-attributes 17/17, byte-identical failure inventories, 0 flips.
  • Direct generic return ParseError.UnexpectedToken; exits: 15 -> 4.

The accepted-program path adds no traversal or allocation; existing declaration and export inventories carry the additional reason/token context.

Sign in to comment on this issue.