ReviewOS

zig-utils/zig-js

Errors: render switch, throw, try, and do-while SyntaxErrors

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

Parent: #899

Problem

Five statement-parser exits discard grammar context in parseDoWhile, parseSwitch, parseThrow, and parseTry: four return a bare UnexpectedToken and one returns a bare ExpectedToken.

Executed on current main (40e64ef), nine representative eval probes expose internal tags. Raw JavaScriptCore 625.1.22 reports:

  • duplicate default and an invalid switch-body item as an unexpected exact token followed by Expected '}' to end a body of a 'switch'.
  • a line terminator after throw as Cannot have a newline after 'throw'.
  • try {} at EOF as Unexpected end of script, and a non-EOF follower as an unexpected exact token followed by Try statements must have at least a catch or finally block.
  • a missing while after do as Unexpected end of script at EOF, or an unexpected exact token followed by Expected 'while' to end a do-while loop.

Implementation

  • Retain the current switch-body token, try follower, and do-while follower.
  • Attach the restricted-production failure to its consumed throw keyword.
  • Let the existing EOF diagnostic mapping produce Unexpected end of script.
  • Match raw JavaScriptCore prose and preserve compact ParseError categories.
  • Add no allocation or source scan to successful statement parsing.

Verification

  • Pin reason, message, and byte offset for all nine probes.
  • Add a focused production eval case for each message/token family.
  • Compare exact-parent switch, throw, try, and do-while test262 subtrees with nonzero denominators and report flips.
9 days ago

Implemented and pushed to main in 029a701.

  • Duplicate/invalid switch clauses and non-EOF try/do-while followers now retain their exact tokens.
  • A newline after throw is attached to the consumed keyword with JavaScriptCore prose.
  • EOF after try {} or do {} reuses the existing end-of-script classifier.
  • Successful statement parsing adds no allocation or source scan.

Validation:

  • parser module: 234/234
  • focused frontend boundary: 1/1
  • raw JavaScriptCore differential: 9/9 byte-identical messages
  • exact-parent test262 comparison: switch 111/111, throw 14/14, try 201/201, do-while 36/36 before and after (0 flips)

This reduces direct return ParseError.UnexpectedToken; sites from 68 to 64 and removes the adjacent bare ExpectedToken exit.

Sign in to comment on this issue.