fix(java): resolve receivers on their declared type, leave library types unguessed

[danusha2345]

Problem

Java already types a call receiver from a local declaration or a plain field. Two gaps remain.

• The declared type is a library class, but the call still gets a project edge. Here the call falls through to the name-only strategies and binds to whichever project method has the same name. Examples:
  • parcel.readInt() on an android.os.Parcel → a project VersionedParcel.readInt;
  • mHandler.post(...) or list.size() → any project post/size;
  • the static Log.e(...) → a project FalsingLog.e.
• Several receiver shapes aren't typed at all, so they're guessed too:
  • this.f and Outer.this.f;
  • a field of an outer class read inside an inner or anonymous class;
  • a declaration with type arguments (Map<String, Foo> byName);
  • a for-each variable;
  • a field chain (this.mOwner.mRepo.save()).

On decompiled Android SystemUI (3,421 Java files), main has about 21.8k call edges whose receiver's declared type is a library class but that land on a project method. Another ~2.9k have a project-class receiver but go to an unrelated class. In playframework's Java sources (790 files) the numbers are ~1.7k and 125.

Fix

All changes are in src/resolution/name-matcher.ts. The extractor already emits the full receiver text, so the kernel and extraction version are unchanged.

• A declared type is read for every receiver shape above. A chain is typed one hop at a time, and each hop's field type is read with its own file's imports.

• A written qualifier is kept: Map.Entry and play.api.mvc.BodyParser<B> stay as written, and import p.Http.Cookie pins that exact nested class.

• When the declared type is a library class, the call gets no edge. A type counts as a library class when:

  • the project declares no JVM type with that name;
  • or an import or written package names something the project doesn't declare (import java.util.Iterator next to a project UByteArray.Iterator);
  • or the only same-named project types are nested in another package and not imported.

  A short all-caps name (T, VH) is taken for a type parameter and left alone.

• A static call on an imported or java.lang library class (Log.d, TextUtils.isEmpty) is left unresolved the same way.

• When no import decides between same-named types, a Java call prefers the Java declaration over a Scala or Kotlin one (play.data.Form vs play.api.data.Form).

This is the Java counterpart of the Kotlin receiver typing in #1933. The two share an idea but not code yet: JAVA_EXTERNAL_TYPE here, KOTLIN_EXTERNAL_TYPE there. Whichever lands second will need a small textual merge in inferJavaFieldReceiverType, whose Java/Kotlin field block this PR narrows to Kotlin.

Measured

Each corpus was indexed with main (ba3c21e) and with this branch. Node counts are identical.

corpus	edges main → PR	lost	gained
SystemUI (decompiled, 3,421 Java files)	352,202 → 330,758	22,793	1,349
playframework (Java part)	72,777 → 72,004	993	220
small Android app (55 Java files)	6,482 → 6,480	2	0

Every gained edge is a typed resolution at 0.9. I hand-checked samples against source; every sampled edge was correct:

corpus	removed guesses	retargeted to the declared type	newly resolved
SystemUI	37	32	40
playframework	45	20	20

Indexing time on SystemUI isn't higher.

Known limits

• Edges point at the declared type, not the runtime class. For example, PARSER.parseFrom → Parser rather than AbstractParser. This is the same choice as for Kotlin.
• Java records aren't indexed as types, an existing extractor gap. A call on a record-typed receiver now gets no edge instead of a guess.
• Wildcard imports aren't in the import mappings, so top-level types of other packages are assumed visible.

Tests

The new __tests__/java-receiver-type.test.ts has 12 cases: 8 fail on main, and 4 are regression guards. The Java-over-Scala guard also fails if the tie-break is removed. The full suite passes: 275 files, 4,730 tests.

🤖 Generated with Claude Code

[danusha2345]

Rebased onto main after the resolution wave. 7 of this PR's 12 cases now pass on main (#2126, #2166, #2169, #2171, #2177), so their code and tests are dropped: the local-variable regex (main's version with type arguments and for-each is kept) and isImportedJavaLibraryClass / JAVA_LANG_CLASSES (Log.d(...) is covered). What remains — all failing on main:

• an outer class's field read inside an anonymous class, and Outer.this.field;
• a library type in a field chain (mOwner.ctx.getResources());
• import java.util.Iterator beside a project q.Bytes.Iterator;
• a Java type vs a same-named Scala type;
• an imported nested class (import p.Http.Cookie).
  The Java field branch now sits after inferMemberReceiverType.

🤖 Generated with Claude Code

[inth3shadows]

@danusha2345, one more receiver form this PR doesn't cover yet, in case it fits its scope: a Java var local whose type comes from another name or a call. This is #1470's case.

// src/com/app/Repo.java
package com.app;
public class Repo { public void query(String sql) {} }

// src/com/app/Svc.java
package com.app;
import org.springframework.jdbc.core.JdbcTemplate;

public class Svc {
  private JdbcTemplate jdbc;
  JdbcTemplate getJdbc() { return jdbc; }
  public void explicitType() { JdbcTemplate t = jdbc; t.query("x"); }
  public void varFromField() { var t = jdbc; t.query("x"); }
  public void varFromParam(JdbcTemplate p) { var t = p; t.query("x"); }
  public void varFromCall() { var t = getJdbc(); t.query("x"); }
  public void varFromNew() { var t = new JdbcTemplate(); t.query("x"); }
}

calls edges out of Svc.java, the same on main (8fe3156) and on this PR's head (be018ef), Linux / Node 22, WASM extractor:

varFromCall  -> src/com/app/Repo.java::query   (wrong)
varFromField -> src/com/app/Repo.java::query   (wrong)
varFromParam -> src/com/app/Repo.java::query   (wrong)
varFromCall  -> src/com/app/Svc.java::getJdbc

explicitType and varFromNew correctly get no edge to Repo.query.

The Java patterns in buildLocalReceiverTypePatterns have no var x = <name or call> case, so the call falls through to the name-only match. That's from reading the code; I haven't traced it. Following var x = y to y's declared type (field, parameter, or a method's return type), or treating a var local of unknown type as unresolved, would remove all three.

If you'd rather keep this PR's scope as it is, I'm happy to send it as a follow-up once this lands.