js_parser: keep legacy-decorated static field initializers inside the class body - #38953
Open
robobun wants to merge 2 commits into
Open
js_parser: keep legacy-decorated static field initializers inside the class body#38953robobun wants to merge 2 commits into
robobun wants to merge 2 commits into
Claude / Claude Code Review
completed
Aug 15, 2026 in 15m 17s
Code review found 1 potential issue
Found 2 candidates, confirmed 1. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 1 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | src/js_parser/p.rs:6647-6650 |
Non-literal computed-key static fields still emitted after the class: super/this in initializer still broken, and relati |
Annotations
Check warning on line 6650 in src/js_parser/p.rs
claude / Claude Code Review
Non-literal computed-key static fields still emitted after the class: super/this in initializer still broken, and relative order vs literal-key decorated siblings now flips
The non-literal computed-key carve-out (commit 1b78564) leaves `static_members` in place, so `@dec static [k] = super.f()` still emits `A[k] = super.f();` after the class and hits the same `SyntaxError` this PR fixes for identifier/literal keys — and it now flips relative order between decorated statics: `@dec static [k] = g(); @dec static a = f();` runs `f()` before `g()` (previously both were in `static_members` and stayed in source order). Both are blocked on #38142's key-hoisting, so probabl
Loading