The #1316 resolver handled `this.injectedField.method()`, but a receiver whose
type comes from a local `const x = new Foo()` binding (Pattern A) or a
type-annotated parameter — including inside a returned closure (Pattern B) —
produced no calls edge, so `affected <method>` silently under-reported.
- _ts_receiver_type_table: augment the per-file type table with local
`new` bindings (name -> constructor type) and bare-typed parameters
(`(svc: Svc)` -> svc: Svc), merged after the constructor-injection entries
(which win on a name clash). Only a bare type_identifier is recorded — an
array/union/generic/qualified/predefined type is skipped (precision).
- walk_calls now descends into an inline/returned JS/TS closure that is not
separately tracked in function_bodies (e.g. `return () => svc.doThing()`),
attributing its calls to the enclosing function, instead of stopping at the
arrow boundary. A tracked-body-id set prevents double-walking const-assigned
arrows.
The existing _resolve_typescript_member_calls then resolves both via the
receiver type with its single-definition guard. Verified on the real-CLI shape
(absolute paths + graphify-out cache): both patterns resolve, ambiguity binds
to the right class (Svc not Cache), untyped/array-typed receivers emit nothing.
5 tests, full suite 2871.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
safishamsiandClaude Opus 4.8
4744dfefca