ReviewOS

zig-utils/zig-js

Errors: render operator, optional-chain, and new-expression SyntaxErrors

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

Parent: #899

Problem

Ten direct bare exits across binary/unary parsing, member access, optional chains, and new discard grammar-specific context.

Executed on current main (029a701), twelve eval probes all expose eval: UnexpectedToken at .... Raw JavaScriptCore 625.1.22 instead reports exact prose for:

  • mixing ?? with &&/|| without parentheses
  • strict deletion of an unqualified identifier
  • a unary expression on the left of **
  • a tagged template in an optional chain
  • new import(...)
  • optional-chain constructor property and call forms
  • invalid ordinary and new. property-name tokens

One adjacent site, new await value inside an async function, has a genuine oracle split: Node 24.18 rejects it as required by the grammar while JavaScriptCore 625.1.22 accepts it. zig-js must preserve the standards-correct rejection and retain the exact await token; no JavaScriptCore message-parity claim applies to that form.

Implementation

  • Retain the current operator/member token at grammar rejections.
  • Retain the optional template token and optional-chain operator offset.
  • Attach strict delete to the identifier spelling and new import to the consumed new keyword.
  • Match raw JavaScriptCore prose for all twelve shared rejections.
  • Keep new await standards-correct with a token-specific diagnostic.
  • Add no allocation or source rescan to successful expression parsing.

Verification

  • Pin reason, message, and byte offset for all twelve JavaScriptCore cases plus the Node-validated new await case.
  • Add a focused production eval case for every message family.
  • Compare exact-parent logical/coalescing, exponentiation, delete, optional-chaining, and new-expression test262 subtrees with nonzero denominators and report flips.
9 days ago

Implemented and pushed to main in 372a9a4.

  • Nullish/logical mixing, strict delete, unary exponentiation, optional tagged templates, malformed member names, new import, and optional-chain constructors now retain exact operators, names, or grammar offsets.
  • All twelve forms rejected by both engines match raw JavaScriptCore 625.1.22 byte for byte.
  • new await value in an async function remains rejected, as Node 24.18 confirms; JavaScriptCore 625.1.22 accepts that nonstandard form, so this case intentionally has no JSC parity claim.
  • Successful expression parsing adds no allocation or source scan.

Validation:

  • parser module: 235/235
  • focused frontend boundary: 1/1
  • raw JavaScriptCore differential: 12/12 shared messages
  • Node grammar oracle: new await rejected
  • exact-parent test262 comparison: 270/270 before and after across seven expression subtrees (0 flips)

This reduces direct return ParseError.UnexpectedToken; sites from 64 to 54.

Sign in to comment on this issue.