Tracking: chained factory/singleton call resolution across statically-typed languages

[colbymchenry]

A call whose receiver is itself a call — a factory / singleton / builder that returns an object — should produce a calls edge to the chained method:

Foo.getInstance().bar();   // bar() should resolve to Foo::bar

This was fixed for C++ (#645) and PHP (#608). A probe of the other statically-typed README languages found the same gap in all of them — and in 7 of the 9 the chained method currently resolves to the wrong class (a same-named method on an unrelated type), which is a correctness bug, not just missing coverage.

The fix is the 3-part #645/#608 mechanism, per language: capture the factory's declared return type, preserve the chained receiver at extraction, then resolve and validate the chained method on the inferred type — so a wrong inference produces no edge, never a wrong one.

Language	Probe result (Foo.factory().method())	Status
Java	edge missing	✅ #751
Kotlin	wrong edge → same-named decoy	✅ #752
C#	edge missing	✅ #753
Swift	wrong edge → same-named decoy	✅ #755
Rust	wrong edge → same-named decoy	✅ #757
Go	wrong edge → same-named decoy (same-package New().Method(); cross-package pkg.New() was #469)	✅ #760
Scala	wrong edge → same-named decoy	✅ #761
Dart	wrong edge → same-named decoy (factory-constructor call also unresolved)	✅ #762
TypeScript	wrong edge → same-named decoy	⏭️ evaluated, skipped (see note)

Dynamically-typed languages can't use this approach (no declared return types to read): Ruby and plain JS are out of scope; Python is partial (optional -> T hints, see #578).

Each language is validated the same way before merge: synthetic decoy + absent-method safety tests, then a real-repo A/B on a public OSS repo (node count unchanged, 0 edges lost, +N chained edges recovered, precision spot-checked).

---

TypeScript — evaluated and consciously skipped

The deterministic chain mechanism was fully implemented and probe-validated for TS (5 synthetic tests passed, including decoy-collision precision and a no-regression instance-chain guard), but real-repo A/B showed a net recall regression, so it was not shipped:

Repo	A/B (unique calls edges)
typeorm (495 files)	+0 / −6
nestjs/nest (600 files)	+0 / −164

Why TS is different from the other 8 languages. The mechanism resolves a chained call from the factory's declared return type. TS code leans heavily on type inference — e.g. NestJS's Test.createTestingModule(metadata) { return new TestingModuleBuilder(...) } has no : TestingModuleBuilder annotation — so the factory's return type can't be recovered, the re-encoded chain can't resolve, and it drops the bare-name edge the existing resolver found. A bare-name fallback (the Go-fallback pattern, runaway-safe) recovered most but not all of them; ambiguous same-named methods across files (compile on both ModuleCompiler and TestingModuleBuilder) still resolved differently than baseline. The removed edges were mostly wrong (baseline mis-resolved .compile() to ModuleCompiler::compile), so it's precision-positive but recall-negative — the opposite of the recall-first invariant.

Zero added edges on both real repos confirms the marginal value is near-nil on real TS: method names are unique enough that the existing bare-name resolution already lands them, and the strict return-type annotations the mechanism needs are too often absent. The synthetic decoy win is real but doesn't occur in practice.

Conclusion: 8 of 9 statically-typed languages + conformance shipped (#751, #752, #753, #754, #755, #757, #760, #761, #762). TypeScript is the one language where gradual typing makes the deterministic chain mechanism a net loss, so it is intentionally not shipped.

---

The three typed README languages the original enumeration missed

The "9 statically-typed languages" list above was incomplete — the README also supports Objective-C, Pascal/Delphi, and Luau, all of which declare return types. Probed and addressed:

Language	Outcome
Objective-C	✅ Shipped (#786). Same wrong-edge gap ([[Foo create] doIt] → a same-named decoy). Ported the mechanism over message_expression; getReturnType skips nullability qualifiers (nonnull instancetype); a class-message factory returns the receiver class by convention, so [[X alloc] init] / singleton chains resolve. SDWebImage A/B +35 / −75 — all corrections (the −75 are wrong init mis-matches retargeted to the right class).
Luau	⏭️ Evaluated, not shipped — additive-safe but +0 on real repos. The mechanism works for annotated factory chains (Foo.create(): Bar then :doIt(); 5 synthetic-style checks pass) and its gap is missing-edge, so unlike TypeScript it's additive (no regression). But Luau is gradually typed and idiomatic code rarely annotates factory returns (Fusion's Expectation.new(value) has no : Expectation; typeof(Bar) returns don't even parse), so real-repo A/B was +0 / −0 on both Fusion AND matter. It doesn't meet the real-repo-win bar, so it was left unshipped (same gradual-typing conclusion as TS, minus the regression).
Pascal/Delphi	🚧 Blocked by a larger prerequisite, out of scope for this mechanism. Pascal is statically typed (so the mechanism would genuinely pay off), but its method-call extraction from procedure bodies is broadly incomplete: paren-less calls (TFoo.GetInstance.DoIt) parse as a bare exprDot (not in the extractor's callTypes), and even paren'd method calls (f.Regular()) produce no edge (no receiver-type tracking for Pascal locals). Building Pascal's call graph is a substantial standalone extractor effort; the chained-call port is a small part of it and a half-fix would be worse than none. Documented as a separate follow-up.

Final tally: the chained static-factory mechanism is shipped for 11 languages — C++, C, PHP, Java, Kotlin, C#, Swift, Rust, Go, Scala, Dart, Objective-C (+ conformance). TypeScript and Luau were evaluated and consciously skipped (gradual typing → the mechanism is +0 / regresses on real code). Pascal is blocked on prerequisite extractor work. Full design record: docs/design/chained-call-resolution.md.

---

Correction: Pascal/Delphi is shipped (#791), not blocked

My earlier "blocked" assessment was wrong — I'd probed only the paren-less form (TFoo.GetInstance.DoIt, which the extractor doesn't emit as a call). The paren'd form (TFoo.GetInstance().DoIt()) extracts fine and hit the chained-call gap like every other language (with a decoy it mis-resolved to a same-named method on an unrelated class). It's a clean port: getReturnType from the typeref; re-encode the chained exprCall-receiver, gated on the Delphi TFoo/IFoo type convention so capitalized variable chains stay bare; a constructor (TFoo.Create().…) or typecast (TFoo(x).…) resolves on the class itself. PascalCoin A/B +19 / −18 (15 of the −18 are correct class→interface retargets — GetInstance(): IAsn1OctetString now resolves on the declared interface). EXTRACTION_VERSION 16.

Revised final tally: 13 languages shipped — C++, C, PHP, Java, Kotlin, C#, Swift, Rust, Go, Scala, Dart, Objective-C, Pascal/Delphi (+ conformance). TypeScript and Luau evaluated and skipped (gradual typing → +0 / regression on real code). The only remaining out-of-scope languages are the genuinely dynamically-typed ones (JavaScript, Ruby, Lua, Svelte, Vue, Liquid; Python is partial via #578). Full design record: docs/design/chained-call-resolution.md.

[colbymchenry]

✅ Java — done in #751 (merged).

Real-repo A/B on google/guava (3,227 files): node count identical (130,925 = 130,925, no explosion), 0 edges lost, +1,507 unique chained edges recovered. Precision verbatim-confirmed (Splitter.on().split(), CacheBuilder.newBuilder().recordStats(), GraphBuilder.directed().build(), nested MultimapBuilder.linkedHashKeys().arrayListValues()). EXTRACTION_VERSION → 6.

Next up: Kotlin (Foo.getInstance().bar() via companion-object factories — note Kotlin's call path is call_expression/navigation_expression, not Java's method_invocation, so the extraction encoding differs).

[colbymchenry]

✅ Kotlin — done in #752 (merged).

Kotlin's baseline dropped chained receivers to a bare method name that mis-matched same-named methods, so this fix is a precision win (resolve-or-drop), not purely additive. Real-repo A/B on arrow-kt/arrow (734 .kt): node count identical (no explosion), +49 validated-correct chained edges (companion-factory + constructor chains), and the removed bare-name edges were wrong (419/438 from test/doc files; the 18 product-code ones are stdlib .apply{}, self-loops, bare-name mismatches — ~0 correct edges lost). EXTRACTION_VERSION → 7.

Implementation notes for the remaining languages: Kotlin needed a capitalized-receiver gate (so instance chains like list.filter{}.map{} keep bare-name behavior and aren't dropped) and constructor-receiver handling (Foo(args).method()). matchJavaCallChain was generalized to matchDottedCallChain, shared by the JVM dot-notation languages.

Next: C# / Swift / Rust / Scala / Dart / TypeScript / Go. The ones whose baseline emits a wrong bare-name edge (most of them) will follow this same precision-win pattern rather than Java's purely-additive one.

[colbymchenry]

✅ C# — done in #753 (merged). Additive like Java (C#'s baseline kept the parenthesized receiver text, so no edges change — only new ones appear).

Real-repo A/B (node count identical, 0 edges lost in both): Newtonsoft.Json (945 .cs) +3; nodatime (488 .cs) +73, verbatim-confirmed (Instant.FromUtc(...).InZone(), Offset.FromHoursAndMinutes(...).Plus(), OffsetDateTimePattern.CreateWithInvariantCulture(...).WithTwoDigitYearMax()). EXTRACTION_VERSION → 8.

Note: C# return types live in the returns field (not type). Extension-method chains correctly don't resolve (the method is on the extension class, not the receiver type) — safe, no wrong edges.

3 of 9 done (Java, Kotlin, C#). Remaining: Swift, Rust, Go, Scala, Dart, TypeScript.

[colbymchenry]

🔧 Conformance-aware resolution — shipped in #754 (a general enabler, not a per-language row).

Chained calls now resolve when the chained method is inherited from a superclass / declared on an interface or protocol the receiver conforms to (e.g. Either.Right(x).combine(...) — combine lives on the parent Either). resolveMethodOnType walks the receiver type's extends/implements edges (still validated), in a second pass after edges are built.

Purely additive — real-repo A/B: arrow-kt/arrow (Kotlin) +22 / −0, nodatime (C#) +0 / −0, node counts unchanged. The arrow additions include edges the Kotlin #752 A/B had dropped (exampleEither22 → Either::isRight), so this partially heals #752. EXTRACTION_VERSION → 9.

This also unblocks the protocol-extension half of Swift — though Swift still needs a separate extractor fix (nested-type extensions like extension KF.Builder get a dot-name inconsistent with the class node) before its fluent chains resolve.

[colbymchenry]

✅ Swift — done in #755 (merged). Two parts: the chained-call mechanism (decoy-safety) + a nested-type extension naming fix (extension KF.Builder was named inconsistently with the KF::Builder type, hiding its conformances/members from the supertype walk).

Real-repo A/B vs main (conformance): Alamofire & Kingfisher both 0/0 (neutral + safe). The prior −168 Kingfisher regression is eliminated; Swift's unique fluent method names already resolved by bare name, so the validated chain path lands the same edges. Value = decoy-collision correctness + the naming fix + consistency. EXTRACTION_VERSION → 10.

5 of 9 done (Java, Kotlin, C#, Swift) + conformance #754. Remaining: Rust, Go, Scala, Dart, TypeScript.