Parent: #899
Problem
An unterminated regular-expression literal is lexed through the string error tag and reaches consumers as UnterminatedString plus an end position. JavaScriptCore reports the unterminated literal itself:
| source | zig-js | JavaScriptCore 625.1.22 |
|---|---|---|
/a | eval: UnterminatedString at 1:3 | Unterminated regular expression literal '/a' |
/[a | eval: UnterminatedString at 1:4 | Unterminated regular expression literal '/[a' |
/a\\ | eval: UnterminatedString at 1:4 | Unterminated regular expression literal '/a\' |
/a\n/ | eval: UnterminatedString at 1:3 | Unterminated regular expression literal '/a' |
The same result occurs after control heads and in initializers.
Implementation shape
The parser already owns the lexical-goal decision and knows when a failed slash reinterpretation was a RegExp scan. At that boundary, retain the source slice from the opening slash to the lexer failure offset and attach a dedicated diagnostic reason. Do not change successful RegExp scanning or add an additional source scan.
Verification
- exact JSC differential for EOF, character-class, escape, line-terminator, control-head, and initializer forms;
- parser diagnostic and focused evaluator tests;
- standalone parser module;
- exact-parent test262 comparison across RegExp literal subtrees.