Parent: #899
Problem
Primary-expression validation still drops grammar context for escaped reserved words, strict-mode legacy literals, and invalid regular-expression flags. Five direct ParseError.UnexpectedToken exits reach JavaScript as the internal tag.
Executed eval probes against raw JavaScriptCore 625.1.22 and current main (4841712f) show the missing distinctions:
| source | JavaScriptCore | zig-js |
|---|---|---|
void v\\u0061r | Unexpected escaped characters in keyword token: 'v\\u0061r' | eval: UnexpectedToken at 1:6 |
'use strict'; 010 | Decimal integer literals with a leading zero are forbidden in strict mode | eval: UnexpectedToken at 1:18 |
'use strict'; '\\1' | The only valid numeric escape in strict mode is '\\0' | eval: UnexpectedToken at 1:19 |
/a/gg | Invalid regular expression: invalid flags | eval: UnexpectedToken at 1:6 |
/a/uv | Invalid regular expression: invalid flags | eval: UnexpectedToken at 1:6 |
Implementation
- Reuse the existing escaped-keyword diagnostic at primary-expression sites and retain the raw escaped spelling.
- Attach distinct strict legacy-decimal and numeric-escape reasons at the literal token offset.
- Classify the existing flag-validation failure when the regex compiler has no pattern diagnostic; keep the retained validation arena and accepted-regex path unchanged.
- Do not add a second flag scan or allocation to successful regex parsing.
Verification
- Byte-for-byte JavaScriptCore differential for escaped reserved spellings, strict legacy decimal/non-octal decimal literals, strict numeric string escapes, duplicate/unknown regex flags, and mutually exclusive
u/vflags. - Focused frontend message checks and the complete standalone parser module.
- Exact-parent test262 comparison over escaped-keyword, strict-mode literal, and RegExp literal/flag subtrees with nonzero denominators and path-level flip accounting.