[arttttt]

Summary

Follow-up to #314 / #472. #472 fixed same-name class disambiguation for Java call sites (@Autowired FooConverter f; f.convert() resolves to the imported FooConverter, not whichever was found first). The equivalent Kotlin path was still broken — and the root cause turned out to be three stacked gaps, only the last of which #472 addressed.

Probed the actual graph to confirm (not guessed): on a synthetic two-module Kotlin repro, fooConverter.convert() with import com.example.b.FooConverter resolved to com.example.a — and there was no field node for fooConverter at all, so inferJavaFieldReceiverType returned null and #472's preferredFqn machinery never even ran for Kotlin.

The three gaps

1. Kotlin class properties weren't indexed. extractField handled Java variable_declarator, C# variable_declaration → variable_declarator, and PHP property_element — but Kotlin property_declaration parses as variable_declaration → simple_identifier (+ user_type), matching none of them (and the identifier-only fallback misses it too, since Kotlin's grammar has no field names). Result: zero field nodes for Kotlin classes, so a val x: Foo receiver's declared type was invisible to the resolver.
2. Kotlin imports weren't parsed. extractJavaImports required a trailing ;, which Java mandates but Kotlin omits (import com.example.Foo). So Kotlin produced zero import mappings and the receiver-FQN disambiguation signal never fired.
3. Disambiguation assumed file-name = class-name. Even with type + import known, resolveMethodOnType matched candidates by file-path suffix (com/example/b/FooConverter.kt) — fine for Java, but Kotlin commonly puts FooConverter in Converters.kt, so the suffix never matched. Now it prefers the candidate whose namespace-qualified name (com.example.b::FooConverter, from feat(jvm): resolve Java/Kotlin imports by fully-qualified name #412's package-directive wrapper) matches the import, falling back to the file-path suffix for Java's layout.

Validation

Synthetic repro (the disambiguation proof): two modules each declaring class FooConverter in Converters.kt. Swapping only the caller's import line swaps the resolved target — import …a.FooConverter → a::FooConverter::convert, import …b.FooConverter → b::FooConverter::convert. Import-driven, not lexical-order-driven. Before the fix both resolved to a.

Real repos (nickbutcher/plaid 258 .kt, android/nowinandroid 310 .kt), indexed on main vs this branch:

	plaid main→fix	nia main→fix
Kotlin field nodes	0 → 485	0 → 329
Kotlin methods	753 = 753	772 = 772
Kotlin→Kotlin calls edges	1118 → 1162	1110 → 1159

The field-extraction fix is decisively validated — hundreds of previously-missing field nodes, with no node/edge explosion (methods stable, +~4% call edges, not multiples). On nia the +49 edges include call sites now correctly resolving to their test doubles (NewsResourceDao::getNewsResources → TestNewsResourceDao::getNewsResources, UserDataRepository::… → FakeUserDataRepository::…) — a real precision gain that fell out of seeing the field's declared type.

Honest scope note: the import-FQN disambiguation (gap 3) is proven on the synthetic repro. Neither real repo contained a true same-name-class-across-packages collision reached through the import + field-receiver shape, so its real-world impact is unmeasured there — it's correct-by-construction and showed zero regressions (no spurious target changes), but I'm not claiming a measured win for it on these two repos. Gaps 1 & 2 are the real-repo-proven part.

Test plan

• New extraction test: Kotlin property_declaration → field node with "<Type> <name>" signature (incl. nullable Foo? → Foo).
• New resolution test: Kotlin same-name classes in non-eponymous files (Converters.kt) — call resolves to the imported package's class, not the lexically-first one.
• Full suite green (tsc --noEmit clean; one pre-existing mcp-roots tinypool/Node-24 worker-crash flake, passes in isolation).
• Real-repo before/after on plaid + nowinandroid (numbers above).

🤖 Generated with Claude Code

[arttttt]

Rebased this branch onto current main — applies cleanly with no conflicts, even though main has since heavily reworked the same files (tree-sitter.ts, import-resolver.ts, name-matcher.ts). tsc --noEmit is clean and the tests pass (resolution.test.ts 61/61; both new tests green). The one error in extraction.test.ts is the pre-existing tinypool/Node-24 V8 worker crash — it reproduces on plain main too, unrelated to this change.

I re-checked that all three fixes are still relevant and not superseded by recent main:

• Imports without a trailing ; — extractJavaImports's regex on main still requires ;, so Kotlin imports still produce zero mappings without this. Still needed.
• Same-name disambiguation by namespace-qualified name — resolveMethodOnType on main still only matches by file-path suffix, no ::-qualified match. Still needed.
• Kotlin property → field node — worth flagging: main now routes property_declaration to extractField via the new kotlin.ts config (fieldTypes/variableTypes), so the original framing ("nothing routes Kotlin properties to extractField") is now slightly stale. But extractField still can't parse the Kotlin variable_declaration → simple_identifier shape, so it produces no field node without the branch here. Verified by removing this block and re-running the test — it fails (expected undefined to be defined) on current main. So this fix is still required, and it now also completes that half-wired routing. Happy to update the PR description to reflect this if you'd prefer.

@colbymchenry would you mind giving this a review when you get a chance? 🙏

[colbymchenry]

Thanks @arttttt, and sorry this one waited so long! It landed in #3013, with you as the commit author: a Kotlin call now picks the class its file imports when two packages share a class name, even when that class lives in a file named something else, and your test covers it. Its other two parts had since landed on main another way, and the Java calls it also fixed are now handled by #1942, which types a Java call by its declared type, so we kept just the lookup change and its test.