issue-2088 plan: a script-scope var reassigned via globalThis.name = … is invisible to subtreeContainsReassignmentOf

[carlos-alm]

What

docs/plans/issue-2088.md's subtreeContainsReassignmentOf (WU-2, condition 4's identifier-resolution chain) detects a write to a module-level name via three AST shapes: a plain/augmented assignment or update expression whose target binds the bare identifier name (as of round 14, resolved through patternBindsName for a destructuring target too — see #2630 for the one shape, a parenthesized target, it still cannot see), and a declaration-less for...in/for...of loop-head target.

None of these shapes covers a write that reaches the same binding through the global object instead of through the identifier directly: in a non-module (classic script) file, a top-level var name = …; also creates a property on globalThis (var bindings at script scope are exposed as globalThis.name; let/const are not). globalThis.name = function () { return this.alpha(); }; (or global.name = … / self.name = … / window.name = … in the appropriate host) elsewhere in the same file reassigns the SAME binding findTopLevelFunctionNodeByName resolves, without ever writing to a bare identifier node at all — it is a member_expression assignment target, a shape subtreeContainsReassignmentOf does not look at, and one patternBindsName does not apply to either (member expressions are not a binding pattern).

This is a decidable, enumerable AST shape (an assignment_expression whose left is a member_expression with object globalThis/global/self/window and property name) — unlike eval/with, which are universal static-analysis limitations no tool can see through — so it sits closer to this design's other accepted, filed recall trade-offs (#2625, #2631, and the round-14 duplicate-declaration fail-safe) than to a Category-F "standard formula/platform limit" the plan already treats MAX_WALK_DEPTH truncation as.

Why this wasn't fixed inline

Recognising a globalThis/global/self/window-qualified write as a reassignment of the SAME module-level var binding requires threading in knowledge of which of several equivalent global-object aliases is in play (all resolve to the same object in a non-strict, non-module script; only globalThis is universally available across hosts and module types) and confirming the resolved declaration is even script-scoped in the first place (a let/const binding is never exposed this way, so the check would need to be conditioned on findTopLevelFunctionNodeByName having resolved through a variable_declaration, not a lexical_declaration) — additional scope for a resolution chain this plan has already found and fixed bugs in across seven rounds, for a pattern with no observed instance anywhere in this codebase today.

Suggested fix shape (not binding — decide at execute/fix time)

Add a fourth disjunct to subtreeContainsReassignmentOf, gated on the resolved declaration having come from a variable_declaration (var) specifically: an assignment_expression whose left is a member_expression with object.text in {'globalThis', 'global', 'self', 'window'} and property.text === name. Add a WU-10 escape-fallback case proving this shape is caught once implemented.

Where

• docs/plans/issue-2088.md — WU-2's subtreeContainsReassignmentOf (condition 4's identifier-resolution chain) and its doc comment.
• 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]

Correction + closure, round 16 (PR #2612).

This issue's own body, and this plan's Risks table, previously grouped #2634 alongside #2625/#2631/round-14 finding 2's #2633 ("sits closer to this design's other accepted, filed recall trade-offs... than to a Category-F..."), as though it were the same kind of thing. It was not, and round 16 corrects both places.

#2625/#2631/#2633 are all DETECTED conditions (a shadow, a reassignment, a duplicate declaration) that the resolution chain deliberately declines to resolve further — genuine recall trade-offs, costing completeness, never soundness. #2634 was a write the write-scan never detected at all — the same kind of gap round 13's and round 14's own pre-fix code had, not the kind that remained after those fixes landed. Live code invoked via a globalThis-qualified reassignment was reported dead; that is not an accepted design boundary, it is a bug.

Closed by a new isGlobalObjectQualifiedWrite check, ORed onto subtreeContainsReassignmentOf's existing assignment/augmented-assignment branch — a member_expression left whose object is globalThis/global/self/window and whose property matches name.

One deliberate simplification, stated for the record rather than left implicit: this check is not gated on the resolved declaration having actually come from a variable_declaration (var) — the only shape for which this relationship holds at all — because that would require threading the caller's own resolved-declaration kind into this whole-file, name-keyed scan, which carries no such context today. The cost is one-directional and already-accepted: this may (harmlessly) treat an unrelated globalThis.name = … write as a reassignment when name actually resolves to a let/const/function declaration no such write could ever affect — over-escape only, never under-escape, and guarded by a new correlation-shape fixture (a non-global obj.run = fn write must not force an escape).

Mirrored in Rust as is_global_object_qualified_write, ORed onto subtree_contains_reassignment_of's equivalent branch.

See docs/plans/issue-2088.md's Risks table (corrected) and Success Criteria, subtreeContainsReassignmentOf's own round-16 essay, and WU-10 escape-fallback case (ap) plus correlation-shape guard 11.