fix(kotlin): resolve imported type calls by qualified name

[mixxer]

Summary

Resolve calls through imported Kotlin and Java types, including Outer.Inner constructors, while rejecting unimported extensions and preserving companion, object and inherited-member calls. #2258 remains the owner of the outside-import guard and external-type identity/visibility follow-up; its implementation and this PR pass together in a separate integration check. Because #2258 is unmerged, this PR retains its existing library-extension behavior until that change lands.

Validation

• Rebased on upstream 1ce1167e6f647f584220926befd86fd1881d3f70; validated head 3a9e74619f6955bebef38d0abe6faaaf90db6873.
• macOS portable backend: full suite passed on Node 22.20.0 and 24.19.0; 6,554 passed and 348 skipped on each runtime.
• macOS native kernel: build passed; parity and relevant Java/Kotlin regression suites passed (1,246 tests).
• Combined with fix(kotlin): a call on an outside type reaches the project's extension on it #2258 using its outside-import guard: both Kotlin regression suites passed (3 tests), including the different-Modifier-type negative control.
• Linux final-head CI: all 12 jobs passed; the workflow checks out this exact head SHA for Node 22/24 portable tests and native/language regressions.
• Combined regression check used latest fix(kotlin): a call on an outside type reaches the project's extension on it #2258 head f25994626fefad6e6b31ff27c56ae0fc2f4f888d; fix(kotlin): a call on an outside type reaches the project's extension on it #2258 remains unmerged and unchanged by this work.

[danusha2345]

I ran this against main (ba3c21e) on three Kotlin Android apps and one Kotlin/Java/C app.

Edge diff. 9 edges were removed and 2 added, and all 11 changes are correct:

• LayoutInflater.from(...) no longer lands on a project TransportType::from (4 edges).
• Log.d/i/w/e inside a Logx wrapper no longer loops back to Logx (5).
• NativeBridge.ensureLoaded/sendfd now resolve to the Java class (2).

The three Kotlin-only apps are unchanged. The build and full suite pass. On main only the nested-constructor assertion fails; the android, androidx, alias, direct, extension and value cases already pass there.

Regressions: four edges that main resolves correctly are dropped. Once the type is explicitly imported, only methods declared on that type or extensions in the same file are accepted, and the return null then blocks every later fallback. Minimal repros:

1. Companion extension in another file. With fun Factory.Companion.extMake() in p/Ext.kt and Factory.extMake() in q/Calls.kt, main resolves to Factory::extMake; the PR gives no edge.
2. Inherited member of an imported object. With object Obj : Base() and import p.Obj, main resolves Obj.hello() to p::Base::hello; the PR gives no edge.
3. Project extension on an imported library type. With fun Modifier.pad() in the project and import androidx.compose.ui.Modifier, main resolves Modifier.pad() to Modifier::pad; the PR gives no edge. This is very common in Compose code.
4. Extension on an imported object, declared in another file. fun Modes.ext() in p/Ext.kt, called as Modes.ext(), gives no edge.

Suggested fix. When the imported type is in the index, fall through to the existing logic instead of returning null. Return null only when the type is external and no project extension is declared on that receiver name.

Minor points:

• kotlinImportedType re-scans the file text with a regex, twice per call, although getImportMappings/importedFqnOf already hold the imports.
• An import line with a trailing comment doesn't match, which falls back to main's behaviour.
• A CHANGELOG entry under [Unreleased] is missing.

It merges cleanly with #1933, and the two are complementary. #1933 types receivers from property and local declarations; it doesn't cover LayoutInflater.from on an imported class, which this PR fixes.

[mixxer]

Addressed the four reported regressions in d30590c. Imported project types can continue through inherited-member resolution; visible project extensions remain eligible, including companion, object, cross-file, and external-type extensions. An extension not imported into the caller stays unresolved. The import check now accepts a trailing line comment, and [Unreleased] has a changelog entry.

The test fixture imports cross-package extensions explicitly because Kotlin's package/import rules make imports file-local; overload resolution considers accessible members and extensions in scope, with members taking priority. This is also consistent with the reference-target and scope model exposed by Kotlin's Analysis API. That is a design comparison, not a claim about Kotlin LSP's closed implementation.

I kept the local import scan for now: getImportMappings currently routes Kotlin through the Java parser, which requires a semicolon and does not parse Kotlin aliases, so it cannot replace this check without a broader import-parser change. The focused Kotlin/resolution/framework tests passed (242), the full suite passed (4,536 passed, 192 skipped), and npm run build passed. The branch merges cleanly with #1933 and current main.

[mixxer]

Fork follow-up: mixxer/codegraph-aosp#8 carries the reviewer regression fixes on top of the fork's merged Kotlin PR. Its Node 22/24, native kernel/AOSP, and final CI checks all passed.

[danusha2345]

Re-checked d30590c against main (ba3c21e), with the native kernel built.

All four reported regressions are fixed: Factory.extMake() (companion extension in another file), Obj.hello() (inherited through an imported object), Modifier.pad() (project extension on an imported library type), and Modes.ext(). The controls are unchanged (named companion, valueOf, typealias, Java inherited static, nested import). A few cases are now better than main:

• An external import whose name matches a project method (TaskStackBuilder.create(), Log.d()) no longer binds to an unrelated project method.
• When two packages declare the same extension, the imported one wins: with import r.dup, the call now goes to r's dup, not p's.

Corpora: three Kotlin-only Android apps are unchanged. A Kotlin/Java/C app has 9 lost and 2 gained, all 11 correct, the same as the previous head.

Tests: the Kotlin-related suites plus resolution.test.ts pass with the kernel (1,226). The CHANGELOG entry is there.

It also merges cleanly with #1933 and the rest of our open resolver work, with no behavioural conflicts. LGTM.

The only conflict is textual, with #1949, in CHANGELOG.md and two additive hunks in name-matcher.ts (the helpers after importedFqnOf and matchReference), so whichever lands second needs a rebase.

[mixxer]

Thanks for rechecking the native-kernel cases and the corpus diff. I agree with the result; I don't see another code change needed from this review. I'll resolve the textual conflict with #1949 on whichever PR lands second.

[mixxer]

Fork integration status: mixxer/codegraph-aosp#8 is merged at 2fd8267. Its post-merge main CI run passed Node 22/24, native kernel/AOSP, and CI checks. I have no additional code change from the LGTM review; upstream #1948 remains available for review at d30590c.

[danusha2345]

Re-checked against main (34ede4d). It still merges cleanly, and main now covers 9 of the 12 assertions in kotlin-imported-type-call.test.ts (the aliased import via #2196). Still missing on main: Outer.Inner() through an imported Java outer class gets no edge, and Modes.hidden() still links to an extension the file does not import; merged, this PR fixes both. But its own test then fails on Modifier.pad(): #2196's outside-import rule (import androidx.compose.ui.Modifier owns the name) returns before matchMethodCall, so the project's own fun Modifier.pad() gets no edge either way — that one is a regression on main for Compose-style extensions, not something this PR introduced. Moving the visible-extension check into or ahead of that rule would keep it.

🤖 Generated with Claude Code

[mixxer]

@colbymchenry @danusha2345 Thanks for the follow-up in #2258 and for carrying forward the visibility check. Both PRs now change the outside-import guard in matchReferenceInner, so it would help to agree on the split before rebasing.

Could #2258 own that guard and its external-type identity/visibility tests, with #1948 retaining the imported Outer.Inner() constructor case, the unimported Modes.hidden() guard, and the companion/object/inherited-member regression coverage? In particular, #2258's different-Modifier-type negative case should be preserved alongside #1948's imported project-type cases.

Which PR would you prefer to land first, and does that division work for you? This would preserve both sets of regression coverage without maintaining competing fixes for the same outside-import guard.

[danusha2345]

@mixxer That division works for me.

• fix(kotlin): a call on an outside type reaches the project's extension on it #2258 owns the outside-import guard in matchReferenceInner (the isJavaOutsideImport branch → kotlinExtensionOnImportedType) and the external-type identity/visibility tests, including the different-Modifier-type negative case.
• fix(kotlin): resolve imported type calls by qualified name #1948 keeps the imported Outer.Inner() constructor case, the unimported Modes.hidden() guard before exact-name matching, and the companion/object/inherited-member coverage.

I'd land #2258 first: it is the smaller change (one helper plus a one-line change at the guard), so #1948 then only has to drop its own hunk at that guard when rebasing — the rest of #1948 is in matchMethodCall and before step 3, which #2258 doesn't touch.

For what it's worth, I already run the two together in a local build in exactly that shape — #2258's form of the guard, #1948's matchMethodCall block and pre-exact-name guard — and both suites pass side by side (kotlin-extension-on-imported-type.test.ts and kotlin-imported-type-call.test.ts). One thing to check when you rebase: with the guard returning through kotlinExtensionOnImportedType, the extension branch inside #1948's importedType block is only reached for an imported project type, so the library-type half of it may be dead by then.

#2258 currently conflicts with main on the CHANGELOG only; I'll re-sync it once the current batch of merges settles. The order is of course @colbymchenry's call.

[mixxer]

Thanks @danusha2345 for confirming the split and testing the two suites together. Agreed: #2258 owns the outside-import guard and external-type identity/visibility tests, including the different-Modifier negative case; #1948 keeps the Outer.Inner() constructor case, Modes.hidden() guard, and companion/object/inherited-member coverage.

Landing #2258 first sounds reasonable. I'll wait for @colbymchenry's final order before rebasing. I've also noted the possible unreachable library-type branch in importedType; the imported project-type behavior and both sets of regression tests need to stay intact.