issue-2088 plan: introducesShadowedBinding's switch_body case may carry the identical using_declaration gap #2632 closed for statement_block

[carlos-alm]

What

Found while implementing round 16's fix for #2632 (PR #2612, docs/plans/issue-2088.md).

introducesShadowedBinding's switch_body case (src/extractors/javascript.ts, the arm handling an unbraced case/default clause) checks each statement for lexical_declaration (via declarationDeclaresName) and, by name field, function_declaration/generator_function_declaration/class_declaration — the identical enumeration its statement_block case uses, and the identical enumeration that (pre-round-16) was missing using_declaration in both places. Round 16 closed the gap for condition 4's resolution question (findResolvingScopeNode) by adding a using_declaration disjunct scoped specifically to a statement_block ancestor — matching exactly what #2632 itself described (a block-scoped using shadow) and nothing more.

The switch_body case carries the identical enumeration gap: an unbraced case/default clause's own using run = mk(); is invisible to introducesShadowedBinding's switch_body arm for the identical reason statement_block's was, and — by the same reasoning #2632 itself gives for why this is a genuine (not merely conservative) gap for condition 4's resolution question specifically — a same-named module-level decoy shadowed only by such a case-level using declaration would resolve to the decoy with full confidence via findResolvingScopeNode, rather than failing safe.

This is not covered by round 16's own fix: that fix's new disjunct in findResolvingScopeNode is gated on current.type === 'statement_block' specifically, matching #2632's own repro shape exactly — it does not check a switch_body ancestor at all.

Direction

Per the exclusion ledger's now-explicit direction labels (see docs/plans/issue-2088.md's Success Criteria section, round 16): this is UNDER-escape if it manifests for condition 4's resolution question, the identical direction #2632 itself is — live code would be reported dead, not a recall trade-off. Per the standing rule the same round establishes, this may not be filed as an accepted limitation once confirmed; it must be fixed. This issue exists to track investigation and closure, not to document it as permanent scope.

Suggested next step

Confirm the switch_body case actually reaches this code path for an unbraced case/default clause containing a using declaration (verify against tree-sitter-javascript@0.25.0's grammar the same way #2632 did for statement_block), then close it the same way round 16 closed #2632: a matching disjunct in findResolvingScopeNode (not a widening of introducesShadowedBinding, for the same reason #2632's own round-16 fix avoided that), mirrored in the Rust engine, with its own escape-fallback fixture.

Where

• src/extractors/javascript.ts (introducesShadowedBinding's switch_body case)
• docs/plans/issue-2088.md — WU-2's findResolvingScopeNode (round 16's own using_declaration disjunct, scoped to statement_block only)
• Related: introducesShadowedBinding's statement_block case can't see using_declaration, missing a shadow for both condition 3 and issue-2088's condition 4 #2632 (the statement_block case of this identical gap, closed round 16)
• Tracking issue: follow-up: receiver-type-aware invoked-property matching to reduce dead-code false negatives #2088. PR: [Plan] issue-2088: receiver-correlated invoked-property evidence for object-literal value-refs #2612.

[carlos-alm]

Confirmed and closed in round 17 of the plan (PR #2612, commit 6ac51c2) rather than carried further.

Verified against the real, already-shipped source: introducesShadowedBinding's switch_body case (src/extractors/javascript.ts:4772-4811) does carry the identical missing-using_declaration gap its statement_block case had before round 16 — same enumeration, same omission. Closed the same way round 16 closed the statement_block case: a fifth disjunct on findResolvingScopeNode alone (not a widening of introducesShadowedBinding), scanning each switch_case/switch_default clause's own direct children for a using_declaration matching via the existing, unmodified declarationDeclaresName.

While closing this, audited every other SCOPE_NODE_TYPES member for the identical gap rather than stopping at switch_body alone (the same completeness discipline this issue's own "suggested next step" implied but didn't require). Found one more instance: introducesShadowedBinding's for_statement case has the same omission — a using-declared C-style for-loop init clause (for (using x = mk(); ...)) shadows an outer decoy exactly like the switch_body case does, verified runnable under Node 22.18 with --js-explicit-resource-management. Closed the same way and credited to this same issue, since it's one root cause reaching a second node type.

Both fixes are mirrored in the Rust engine (WU-7), each independently re-verified against the real, already-shipped Rust source rather than assumed to mirror the TS side. New fixtures: escape-fallback cases (ar) (switch_body) and (av) (for_statement), each asserting escapes = 1; correlation shapes 13 and 17 guard that both new disjuncts are gated on name, not merely on the ancestor's presence.

Also fixed the plan's own standing rule, which this issue itself slipped through: its wording scoped "must be fixed, never filed" to Success Criteria's own list, letting this issue sit unlabelled in Out of Scope (a different, physically earlier section) for a round. The rule now explicitly spans both lists.

Full details in docs/plans/issue-2088.md's findResolvingScopeNode doc comment (round 17 essays), the Risks table, and Success Criteria.

[carlos-alm]

Reopening: the for_statement half of the round-17 fix (this issue's own second paragraph, "Found one more instance") was never actually reachable. Closing it on that fix was a mistake.

What went wrong

Round 17's findResolvingScopeNode disjunct for for_statement scanned each direct child for child?.type === 'using_declaration'. That type can never appear there: tree-sitter-javascript@0.25.0's for_statement rule (grammar.js:375-390) admits only choice($.lexical_declaration, $.variable_declaration), a bare expression, or $.empty_statement as its initializer — confirmed independently by the compiled node-types.json's own initializer field schema (lexical_declaration, variable_declaration, expression, sequence_expression, empty_statement — five types, no more). using_declaration is declared as its own top-level rule, reachable only through the general declaration/statement production — the same route that makes it valid inside a switch_case body (this issue's own first fix, still correct) or a statement_block, but never inside a C-style for(;;)'s closed three-clause head.

Parsed directly with the real, installed grammar (web-tree-sitter against tree-sitter-javascript's own published tree-sitter-javascript.wasm), for (using run45 = disposable45; true; ) produces a for_statement whose initializer position holds an ERROR node (ERROR "using run45 = disposable45"), never a using_declaration, with rootNode.hasError === true for the file. The disjunct's own type check could never match.

Round 17's support for treating this as "grammar-valid" was that the equivalent snippet "parses and runs under Node 22.18 with --js-explicit-resource-management" — true, but that is a claim about V8's own experimental, in-progress Explicit Resource Management implementation, not about tree-sitter-javascript, the grammar this design's own findResolvingScopeNode/introducesShadowedBinding actually walk. The two disagree for this exact construct. Re-running the same snippet confirms V8 does still accept it (leniently, as an in-progress feature) while tree-sitter does not — the runtime-behavior claim and the parse-tree-shape claim are independent facts, and only the first was ever checked.

Fix (this round)

Keyed on the actual parse shape instead: findResolvingScopeNode's for_statement disjunct now detects a direct-child ERROR node whose own text begins with using/await using (the await using spelling nests its own ERROR one level deeper, inside a misparsed assignment_expression, since await outside an async function is an ordinary identifier — checked at both levels) and fails safe UNCONDITIONALLY, matching the with_statement disjunct's own shape: there is no clean declaration node here to resolve a name against, so this doesn't try to. introducesShadowedBinding remains untouched.

Also rebuilt correlation shape 17 (its own round-17 original fixture was grammar-invalid in the identical way and never exercised the code path it claimed to guard) and added escape-fallback case (aw) for the await using spelling.

This also prompted a new standing rule in the plan: every fixture must be parsed with the real tree-sitter-javascript grammar, and the node type(s) a fix keys on confirmed present in the resulting tree — a snippet "running under Node" is not sufficient evidence for a claim about what tree-sitter produces.

Where

• src/extractors/javascript.ts (findResolvingScopeNode's for_statement disjunct — not yet implemented; this is a plan-doc correction)
• docs/plans/issue-2088.md — findResolvingScopeNode's own doc comment (round 18 essay), escape-fallback cases (av) (corrected)/(aw), correlation shapes 16/17 (rebuilt)
• Tracking issue: follow-up: receiver-type-aware invoked-property matching to reduce dead-code false negatives #2088. PR: [Plan] issue-2088: receiver-correlated invoked-property evidence for object-literal value-refs #2612.