Two distinct js_parser bugs surfaced while loading google.com:
1. `replace(/=/g, "")` — the tokenizer eagerly produces `SlashAssign`
for `/=`, but in expression-start position (after `(`, `,`, etc.) it's
actually a regex literal. parse_primary now re-scans `SlashAssign` as
a regex from the `/` byte, mirroring the existing `Slash` handling.
2. `for (E in N=u, f.T) {}` — ES262 §14.7.5.1 specifies the for-in RHS as
`Expression` (which permits comma sequences), but we were calling
`parse_assignment` and stopping at the first comma. Switched all three
for-in sites (var, pattern, lhs-expr) to `parse_expression`. Left
for-of alone since the spec gives it `AssignmentExpression`.
Diagnostic improvements that helped track these down:
- log_script_error now also recognizes `Span { start: N, end: M }`
parser-error format and snippets the source by raw bytes (UTF-8 safe).
- eval/indirect-eval `SyntaxError` messages now append a
`[near: ...»«...]` window of the eval source so the next failure shows
what's actually in the eval'd substring instead of an opaque offset
into a string the caller never sees.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
cca092ced9