issue-2088 plan: param-flow branch of escape analysis has the same alias-transitivity gap round-4 fixed for aliases

[carlos-alm]

What

docs/plans/issue-2088.md's escape-analysis design (condition 3 of computeObjectLiteralSiteEscapes, WU-2) has the same transitivity gap for its parameter-flow branch that PR #2612 round 4 (Greptile) just caught for its alias branch, and that fix does not cover this case.

Condition 3 treats a bare-identifier argument to a "LOCALLY-DEFINED, NON-EXPORTED function" as a tracked reference, on the grounds that paramBindings (Phase 8.3c, already shipped) propagates the site into the callee's scoped parameter key. Verified against the real, already-shipped primitive at src/domain/graph/resolver/points-to.ts:96 (buildParamFlowConstraints): it only adds the constraint row pts(f::paramName) ⊇ pts(x) — it has no escape-safety check of its own, and nothing in the plan's condition 3 examines what the callee's body subsequently does with that parameter.

So f(T) is accepted as tracked even when f's body does e.g. function f(t) { importedFn(t); } — the parameter t escapes through an unmodeled channel exactly the way u did in the alias case (const u = T; importedFn(u);), but nothing in the current design catches it, because the check never looks inside f's body.

Why this wasn't folded into #2612 directly

Scope discipline: PR #2612 round 4 is fixing the alias branch specifically (what Greptile flagged); this is a structurally analogous but independent branch of the same condition, not yet flagged by any reviewer, and fixing it requires deciding how to scope a recursive/transitive check into another function's body (parameter shadowing rules there are less obviously reused from the existing introducesShadowedBinding/findDeclaringScopeLine machinery than the alias case's same-scope walk was) — worth its own focused look rather than expanding round 4's diff.

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

Mirror round 4's fix: when condition 3 accepts a bare-identifier argument to a local, non-exported callee, additionally require that condition 3 (recursively) also holds for the callee's corresponding parameter name, scoped to occurrences inside that callee's own body. Add a regression case to WU-10's escape-fallback test list (tests/integration/issue-2088-escape-fallback.test.ts) demonstrating f(T) where f's body passes its parameter to an imported/exported function must still classify the site escaping.

Where

• docs/plans/issue-2088.md — WU-2's allReferencesTracked description (condition 3, the arguments-position branch) and WU-10's escape-fallback test list.
• 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]

Re-scoping this issue after commit 515140a on PR #2612.

Why: as filed, this issue's "Where" pointed at docs/plans/issue-2088.md WU-2 condition 3 and WU-10 — i.e. at the plan that is still awaiting human approval. That made it circular: approving the plan would have meant authorising a build with a known live-code-reported-dead path, tracked by an issue saying "fix the plan you just approved."

An independent review of the plan at head 62606d0 confirmed the defect was real, not theoretical:

const P = { beta: fnB };
function use(t) { register(t); }   // `register` is imported
use(P);

P unexported + use local and unexported meant escapes = false, which made T1 exclusive and skipped the T2 fallback. Since cross-module site propagation does not exist, the real t.beta() inside the imported module produced no correlated evidence, so fnB would have been reported dead where today's invokedNames predicate correctly reports it live. That is the false-negative to false-positive conversion the plan's own hard rule forbids.

What changed: commit 515140a drops the parameter-flow branch from WU-2b's condition 3 entirely. A bare-identifier argument to a function now always marks the site escaping, regardless of whether the callee is local and non-exported, so the site falls back to T2 — today's exact bare-name predicate. The unsound path is closed by exclusion rather than deferred.

Supporting changes in the same commit:

• allReferencesTracked no longer takes localNonExportedFns.
• WU-4's "parameter flow ... comes for free" claim is corrected: buildParamFlowConstraints still propagates pts(callee::paramName) ⊇ pts(argName), but it has no escape check of its own and is documented "Scope: intra-module only", so that constraint is harmless but unused for this purpose.
• WU-10's correlation test drops from four canonical shapes to three. The old case 4 moves into the escape-fallback test as case (f), asserting escapes = 1 and live-via-T2. This mattered: as previously written it asserted escapes = 0 for this branch, so the test suite would have certified the unsound classification as correct behaviour.

This issue is therefore no longer a plan defect. It is re-scoped to a future recall enhancement: extend correlation to the parameter-flow shape by recursing into the callee's own body to verify the parameter stays tracked there, mirroring the recursion the alias/rebinding branch already does. That needs a decision on how parameter shadowing is scoped inside another function's body, which is why it was not folded in here.

Deliberately leaving this open, and leaving the title and body as originally filed for provenance — this comment is the re-scope record.

[carlos-alm]

Re-scoping this issue, without closing it.

PR #2612 commit 515140a ("docs: treat param-flow positions as escaping in WU-2 condition 3") closed the soundness gap this issue describes — but by a different, more conservative route than the "Suggested fix shape" above proposed.

Instead of recursing condition 3 into the callee's body (mirroring round 4's alias fix), the plan now drops the parameter-flow branch from condition 3 entirely: a bare-identifier argument to a function — regardless of whether the callee is local, non-exported, and itself uses the parameter in a tracked position — no longer counts as a tracked reference at all. Such a site always resolves as escaping and falls back to T2 (today's exact bare-name predicate). Concretely, f(T) now always marks T's site escaping, whether or not f's body does something safe or unsafe with its parameter — the plan no longer tries to tell the difference. Docs updated: WU-2b's condition 3 description, WU-4's "comes for free" claim, Success Criteria bullet 3, and the WU-10 test lists (the former correlation case 4 moved to the escape-fallback test as new case (f), asserting escapes = 1 and live-via-T2).

That closes the false-negative-to-false-positive risk this issue flagged, so it's no longer a defect blocking the plan's approval — which also resolves the circularity of this issue pointing at a plan that was, at the time, still awaiting approval partly because of this same gap.

What's left is exactly this issue's original "Suggested fix shape": recursing condition 3 into the callee's own body so a provably-safe f(T) (where f only ever uses its parameter in a tracked position) can still be credited as correlated (T1) evidence instead of falling back to T2. That's real, valid future work — it just is not a soundness requirement for the current plan, since the conservative fallback is now unconditional. Re-scoping this issue's category from "plan defect" to a recall enhancement: extend allocation-site correlation to the parameter-flow branch via recursion into the callee body, on top of the plan in #2612/docs/plans/issue-2088.md once it lands.