fix(resolution): library-method calls on untyped receivers need receiver evidence (Rust, Go, Python, Kotlin, Scala, C#, Java)

[danusha2345]

Rebased onto the 2026-09-27 main. #1944 landed as #2032, so this PR now stands on main alone: 5213d7c on top of fa6dd01. It also absorbs #1953, the Java list: that PR only added to the same library-methods.ts and the same check, so the two would have conflicted as separate PRs. #2028 covers JS/TS built-in names; this PR covers the other languages, so the two don't overlap.

Problem

For many member calls, no receiver type reaches the resolver, and the call then binds to the only project method with the same name. There are two paths.

• Bare-name chains. The extractor emits just the method name for chain receivers: Rust x.f().m(), a.b.m(), x?.m(); Kotlin/Scala chains with a lowercase root; Go chains deeper than two hops; Python a.b.m(). Exact-match then binds them at 0.9, 0.7 or 0.4.
• Untyped plain receivers x.m(). These reach matchMethodCall's name-only strategy 3.

Where the method name belongs to the language's standard library, the call is almost always that library method, and the one project method with that name collects every such call:

• name.len() / v.iter().all() → a Rust AppLog::len / SpeedProfile::all: about 500 edges in one Rust GUI.
• conn.Close() → a Go rotatingLogWriter::Close.
• d.setdefault(k, []) → a project setdefault.
• Task.Run(...) → a C# Run.
• opt.map/get/foreach → Scala project methods.

Precision on main, from 40 randomly sampled edges per language covering both paths:

language (corpora)	call sites	precision
Rust (2 repos)	1,318	16/40
Scala (playframework)	7,345	~18/40
Go	352	28/40
Python (Flask + app)	958	~31/40
Kotlin (3 repos)	1,146	~34/40

Fix

The fix is in the resolver only: no extractor or kernel change and no re-index.

• Curated lists. library-methods.ts holds per-language lists of standard-library method names for Rust, Go, Python, Kotlin, Scala and C#.
• The rule. For a name on the list, a candidate is kept only when the receiver's own name shares a word with the candidate's type. A free function's module path counts as its type for this check.
  • The receiver's name is the last name in its chain: self.state.log.clear() → log keeps AppLog::clear.
  • A capitalized chain root also counts: GpsMode.ON.next().
• Where it applies. The check runs in strategy 3 and in exact-match and fuzzy, on the one candidate a strategy commits to. It never filters the candidate pool, so it can't turn a crowd into a lone survivor.
• Bare-named refs. The receiver is read from the call site.
• Untouched. self/this/super/base/cls receivers and implicit-this calls. Typed receivers resolve before any of these strategies and never reach the check.

Measured

Base is #1944. Nothing was gained, node counts are unchanged, and every lost group was checked by hand:

corpus	lost call sites	true edges among them
Rust (2 repos)	927	~4
Kotlin (3 repos)	144	~8–10
Go (2 repos)	245	1
Python (2 repos)	130	~15 (flask.g.setdefault/pop: a one-letter receiver gives no word evidence)
C# MediatR	29	0 (Task.Run ×16, e.ToString ×12)
playframework	2,545	~20–40

After the fix, 39 of 40 sampled remaining Rust edges are correct. Scala's remaining noise comes from ambiguous project method names (header, value, apply), which this change doesn't touch.

Tests

__tests__/library-method-calls.test.ts covers Rust, Kotlin, Python, Go and C#. Five of its six cases fail on the base. The controls cover:

• a typed receiver;
• self.setdefault;
• a Kotlin implicit-this call;
• a type-rooted chain;
• a receiver named after its type.

The full suite passes: 276 files, 4734 tests.

---

Java (was #1953)

Problem

The list above of standard-library method names. A call with one of those names on an untyped receiver no longer binds to a lone same-named project method unless the receiver's name shares a word with that method's class. Java wasn't on the list, and its name-only matches have the same problem.

• data.put(k, v) on a test Map → a project RejectingMap::put. That's 1,115 call sites in playframework.
• Other Java method calls: s.charAt(i), list.size(), CONSTANT.equals(x) and mView.getResources() bind to whichever project class declares that name.
• Static calls through wildcard imports: Collections.emptyMap() and String.valueOf(x) under import java.util.*. The check for imported library classes only knows named and java.lang imports, so wildcard imports slip through.
• Calls through a constant: Integer.TYPE.equals(...) and X.KEY.equals(...) get no receiver type, so they bind by name too.

On our integration build, which already has the Java receiver typing from #1942, name-only edges with a JDK/Android method name are about 30% correct on playframework's Java and about 40% on decompiled Android SystemUI. These were checked by hand.

Fix

• A java list in library-methods.ts, 64 names:

  • Object: equals, hashCode, toString, getClass, compareTo;
  • collection, map and iterator methods;
  • String methods;
  • Optional/Stream methods;
  • a few Android framework methods: getResources, getSystemService, findViewById, postDelayed, removeCallbacks, setVisibility, startActivity.

  Names that projects commonly declare themselves were left out: post, of, apply, run, call, start, stop, getId, getContext and similar. Playframework alone declares apply 60 times.

• JAVA_STD_CLASSES. A call on one of these classes counts as a library call whatever the method name, also when written as java.lang.X: Objects, Arrays, Collections, Optional, List, Map, Set, UUID, String, the boxed number types, Math, System, Thread. A project class with the same name keeps its edge through the existing receiver-word check.

• Constant receivers. A Java receiver ending in an ALL_CAPS constant gives no type evidence. INSTANCE is exempt.

Typed resolution at 0.9 is untouched.

Measured

Node counts are unchanged in every pair, and no edges were gained.

pair	corpus	lost	correct among lost
#1947 → this branch	playframework (Java)	1,356	none found in a 60-edge sample + a receiver/target-class scan
#1947 → this branch	decompiled SystemUI	1,133	none found
integration (#1942 + #1947) → + this	playframework	36	0 (all checked)
integration (#1942 + #1947) → + this	SystemUI	149	2 (ByteString.EMPTY.equals, removed by the constant rule)

Five other corpora are unchanged: two Kotlin apps, a Kotlin/C app, a small Java/Kotlin app and a Rust app.

Tests

New Java cases in __tests__/library-method-calls.test.ts:

• Must not bind (5 cases, all bind to project methods on the base): list.get(0), s.toString(), Objects.hash(a), Collections.emptyMap() under import java.util.*, Registry.KEY.equals(a).
• Must still bind: a typed field (registry.get → Registry::get), a bare size() and this.get() inside the owning class, and a receiver named after its type (userRegistry.size()).

The full suite passes: 276 files, 4734 tests.

🤖 Generated with Claude Code

[danusha2345]

Rebased and reworked onto main's new structure. Rust, Kotlin and C# (and static Objects.hash / Collections.emptyMap) are covered on main by stdMethodNames / sharesReceiverWord (#2166, #2167, #2177), so library-methods.ts and isUnevidencedLibraryCall are gone. What remains extends main's sets:

• Python: options.setdefault on a same-file class; Scala: m.getOrElse on an untyped val; Java: var data = load(); data.get(...) → RejectingMap::put etc. — Python / Scala / Java method sets added to stdMethodNames, and cls to the "receiver is the class itself" list;
• Go: conn.Write on net.Conn — rather than adding Write/Close to GO_STD_METHODS (left out there on purpose), a package-qualified parameter type is now read, so fix(resolution): a receiver declared with an outside type calls that type #2169's "outside type is not a project method" applies.
  4 of the 5 cases in the rewritten test fail on main.

🤖 Generated with Claude Code

[danusha2345]

Rebased onto main. No maintainer PR has covered this one since the last rebase, so the Python, Scala and Java parts are unchanged.

I removed the Go part (reading conn net.Conn as a typed parameter). After #2361, Go receiver types are resolved in the package that declares them, and this PR read the qualified type without checking that net is a package outside the project, so net.Conn could land on a project type named Conn. #1954 reads the same parameter with that check and now carries the conn.Write test.

The remaining check uses isStdMethodName from #2351 instead of its own lookup.

🤖 Generated with Claude Code