Fix await using expression printing using as await - #31324
Merged
Claude / Claude Code Review
completed
May 24, 2026 in 20m 59s
Code review found 2 potential issues
Found 3 candidates, confirmed 2. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 0 |
| 🟣 Pre-existing | 2 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟣 Pre-existing | src/js_parser/parse/mod.rs:922 |
await using.foo ** x not rejected (TAsteriskAsterisk check runs before parse_suffix in the using-identifier fallback) |
| 🟣 Pre-existing | src/js_parser/parse/mod.rs:922 |
Same raw→raw2 bug left unfixed in Zig reference (parse.zig:719) |
Annotations
Check notice on line 922 in src/js_parser/parse/mod.rs
claude / Claude Code Review
await using.foo ** x not rejected (TAsteriskAsterisk check runs before parse_suffix in the using-identifier fallback)
🟣 Pre-existing (distinct from the line-885 note above): in this same fallback, the `TAsteriskAsterisk` check at line 936 runs *before* `parse_suffix` at line 939, so `await using.foo ** x` (and `using[0]`/`using()`/`using`tpl`` followed by `**`) is silently accepted as `(await using.foo) ** x` instead of the spec-required SyntaxError. The else-branch (line 933) and `parse_prefix`'s await handler both check `**` *after* parsing the prefix expression, so `await x.foo ** y` for any other `x` is cor
Check notice on line 922 in src/js_parser/parse/mod.rs
claude / Claude Code Review
Same raw→raw2 bug left unfixed in Zig reference (parse.zig:719)
🟣 Pre-existing parity gap: the Zig reference this code was ported from still has the identical `raw` → `raw2` bug at `src/js_parser/parse/parse.zig:719` (`.ref = try p.storeNameInRef(raw)` inside the `raw2 == "using"` fallback). That `parseExprOrLetStmt` is still wired in via `p.zig:94` and called from `parse_stmt.zig`, so any build path routed through the Zig parser (e.g. the WASM target via `main_wasm.zig`) retains the original `await await instanceof o` miscompile, and a future re-sync from t
Loading