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)	⬜
Scala	wrong edge → same-named decoy	⬜
Dart	wrong edge → same-named decoy (factory-constructor call also unresolved)	⬜
TypeScript	wrong edge → same-named decoy	⬜

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).

[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.