Found during round-6 review of #2612 (issue-2088's implementation plan).
Problem
computeObjectLiteralSiteEscapes (WU-2 of docs/plans/issue-2088.md) marks a site escaping whenever the literal itself defines a method or function-valued property that references this in its body — e.g.:
const T = { alpha: fnA, run() { return this.alpha(); } };
T.run();T's only reference (T.run()) is otherwise a tracked, correlated call position. But this inside run() is not a reference to the binding T at all, and nothing in the points-to solver binds it to T's site: the solver's only this key is ${callee}::this (src/domain/graph/resolver/points-to.ts:548-554), seeded from thisCallBindings only for .call(ctx)-style invocations, not for plain obj.method() calls. So this.alpha() produces no correlated (T1) evidence for alpha, no matter how run is called.
Current status
Conservative exclusion: any literal containing a method/function-valued property whose body references this is marked escaping outright, falling back to today's T2 bare-name evidence (collectInvokedPropertyNames already credits this shape — it accepts any truthy receiver, 'this' included: src/domain/graph/builder/call-resolver.ts:97). Sound, but costs recall: such a literal can never get the tighter T1-exclusive treatment even when every actual call site is legitimately correlated.
Suggested fix shape (not binding — decide at execute/fix time)
Extend the design so the solver seeds a site-scoped this binding for methods defined directly inside a tracked object-literal site (e.g. pts(${site}::this) ⊇ pts(siteKey)), and have the tier ladder verify, per call site, that the specific invocation reaching a given this.k() is itself a correlated call on this site — not just that some call to the enclosing method was correlated once. This needs per-call-site correlation rather than per-property evidence, which is materially more work than the initial #2088 delivery scopes.
Where
Found during round-6 review of #2612 (issue-2088's implementation plan).
Problem
computeObjectLiteralSiteEscapes(WU-2 ofdocs/plans/issue-2088.md) marks a site escaping whenever the literal itself defines a method or function-valued property that referencesthisin its body — e.g.:T's only reference (T.run()) is otherwise a tracked, correlated call position. Butthisinsiderun()is not a reference to the bindingTat all, and nothing in the points-to solver binds it toT's site: the solver's onlythiskey is${callee}::this(src/domain/graph/resolver/points-to.ts:548-554), seeded fromthisCallBindingsonly for.call(ctx)-style invocations, not for plainobj.method()calls. Sothis.alpha()produces no correlated (T1) evidence foralpha, no matter howrunis called.Current status
Conservative exclusion: any literal containing a method/function-valued property whose body references
thisis marked escaping outright, falling back to today's T2 bare-name evidence (collectInvokedPropertyNamesalready credits this shape — it accepts any truthy receiver,'this'included:src/domain/graph/builder/call-resolver.ts:97). Sound, but costs recall: such a literal can never get the tighter T1-exclusive treatment even when every actual call site is legitimately correlated.Suggested fix shape (not binding — decide at execute/fix time)
Extend the design so the solver seeds a site-scoped
thisbinding for methods defined directly inside a tracked object-literal site (e.g.pts(${site}::this) ⊇ pts(siteKey)), and have the tier ladder verify, per call site, that the specific invocation reaching a giventhis.k()is itself a correlated call on this site — not just that some call to the enclosing method was correlated once. This needs per-call-site correlation rather than per-property evidence, which is materially more work than the initial #2088 delivery scopes.Where
docs/plans/issue-2088.md— WU-2'scomputeObjectLiteralSiteEscapes(condition 4) andliteralHasUnmodeledThisReference; WU-10's escape-fallback case (g).