Found during round-7 review of #2612 (issue-2088's implementation plan).
Problem
docs/plans/issue-2088.md's escape-analysis design (isTrackedReferencePosition, WU-2) requires a subscript call's index to be a string, or a template_string containing no ${…} interpolation, before treating it as a statically-known property name — mirroring the extractor's own guard exactly: extractSubscriptCallInfo (src/extractors/javascript.ts:5888) and its Rust mirror extract_call_info (crates/codegraph-core/src/extractors/javascript.rs:6255, subscript arm at :6469-6489) both only emit a named, receiver-carrying computed-literal Call when !methodName.includes('$'); an interpolated template like T[`al${part}`]() falls through to <dynamic:unresolved> — no name, no receiver, for either engine.
So an interpolated template-string subscript call can never produce collectInvokedPropertySites evidence for any specific property, regardless of how the receiver is referenced elsewhere — round 7 excludes it from the tracked set for exactly this reason (the same reasoning that already excludes an identifier-keyed subscript call, #2619).
Impact
Recall-only: T[`al${part}`]() really does invoke T.alpha at runtime whenever part === 'pha', but no existing channel proves it statically. The site correctly falls back to T2.
Fix sketch
Would need partial constant-folding of the template's static segments against the property names actually declared on the literal (e.g. matching `al${x}pha` against every key when x's possible values are unknown is unsound; matching only when x is itself provably a literal-valued alias is the safer version) — meaningfully more machinery than the current static-key check, and not obviously worth it relative to how rarely dispatch tables are keyed by interpolated templates. Related to #2619's broader "computed dispatch key" gap; consider closing both together.
Not attempted in #2612 — that PR is a docs-only plan revision.
Found during round-7 review of #2612 (issue-2088's implementation plan).
Problem
docs/plans/issue-2088.md's escape-analysis design (isTrackedReferencePosition, WU-2) requires a subscript call's index to be astring, or atemplate_stringcontaining no${…}interpolation, before treating it as a statically-known property name — mirroring the extractor's own guard exactly:extractSubscriptCallInfo(src/extractors/javascript.ts:5888) and its Rust mirrorextract_call_info(crates/codegraph-core/src/extractors/javascript.rs:6255, subscript arm at :6469-6489) both only emit a named, receiver-carryingcomputed-literalCall when!methodName.includes('$'); an interpolated template likeT[`al${part}`]()falls through to<dynamic:unresolved>— no name, no receiver, for either engine.So an interpolated template-string subscript call can never produce
collectInvokedPropertySitesevidence for any specific property, regardless of how the receiver is referenced elsewhere — round 7 excludes it from the tracked set for exactly this reason (the same reasoning that already excludes an identifier-keyed subscript call, #2619).Impact
Recall-only:
T[`al${part}`]()really does invokeT.alphaat runtime wheneverpart === 'pha', but no existing channel proves it statically. The site correctly falls back to T2.Fix sketch
Would need partial constant-folding of the template's static segments against the property names actually declared on the literal (e.g. matching
`al${x}pha`against every key whenx's possible values are unknown is unsound; matching only whenxis itself provably a literal-valued alias is the safer version) — meaningfully more machinery than the current static-key check, and not obviously worth it relative to how rarely dispatch tables are keyed by interpolated templates. Related to #2619's broader "computed dispatch key" gap; consider closing both together.Not attempted in #2612 — that PR is a docs-only plan revision.