Skip to content

Fix await using expression printing using as await - #31324

Merged
Jarred-Sumner merged 3 commits into
mainfrom
farm/b916b682/fix-await-using-expr
May 24, 2026
Merged

Fix await using expression printing using as await#31324
Jarred-Sumner merged 3 commits into
mainfrom
farm/b916b682/fix-await-using-expr

[autofix.ci] apply automated fixes

2df3d79
Select commit
Loading
Failed to load commit list.
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

See this annotation in the file changed.

@claude 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

See this annotation in the file changed.

@claude 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