Repository navigation
fix(kotlin): a call on an outside type reaches the project's extension on it - #2258
Open
danusha2345 wants to merge 1 commit into
Open
danusha2345 wants to merge 1 commit into
danusha2345 wants to merge 1 commit into
Conversation
danusha2345
pushed a commit
to danusha2345/codegraph
that referenced
this pull request
Oct 1, 2026
…bymchenry#2259, colbymchenry#2260) into fork main Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
danusha2345
force-pushed
the
fix/kotlin-project-extension-on-imported-type
branch
3 times, most recently
from
October 7, 2026 11:51
d0236ea to
35d410d
Compare
…n on it colbymchenry#2196 made a Kotlin import from outside the project own its name, so `Modifier.fillMaxSize()` after `import androidx.compose.ui.Modifier` no longer lands on a same-named project method. The rule returns before any other strategy, so a project extension on that type - Compose's `fun Modifier.pad()`, indexed as `Modifier::pad` - could not be reached by `Modifier.pad()` either (nor `Color.fromHex()` on a `fun Color.Companion.fromHex()`). Inside the rule, a Kotlin `Type.member` call now resolves to a project extension `Type::member` that the call site can see (same file or package, or imported by name or `.*`, as for other top-level Kotlin declarations) and whose own file imports the same type. Anything else stays unlinked, as before. The visibility check follows the idea of `kotlinExtensionInScope` from the discussion in colbymchenry#1948. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
danusha2345
force-pushed
the
fix/kotlin-project-extension-on-imported-type
branch
from
October 7, 2026 16:08
35d410d to
48d1d19
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
#2196 made a Kotlin import from outside the project own its name: after
import androidx.compose.ui.Modifier,Modifier.fillMaxSize()no longer lands on a same-named project method. That rule returns before every other strategy, so a project extension declared on the imported type can't be reached either:(Before #2196 this call was already dropped by the "receiver names a type the project doesn't declare" guard in
matchMethodCall; #2196 adds a second block in front of every strategy, so it can no longer be fixed there.)Change
Inside the outside-import rule, a Kotlin
Type.membercall now resolves to a project extension indexed asType::memberwhen.*(the existingisKotlinTopLevelVisible/kotlinFileScope), andjavax.lang.model.element.Modifieris not Compose's).If several qualify, only one in the calling file is taken; otherwise no edge. Everything else stays unlinked as before —
Modifier.fillMaxSize()included.Color.fromHex()on afun Color.Companion.fromHex()is covered the same way. Chains through an outside call (Modifier.fillMaxSize().pad()) are untouched: the outside call's return type is unknown, and they did not resolve before #2196 either. An instance receiver (val m: Modifier; m.pad()) already resolved on main and is unaffected.Tests
__tests__/kotlin-extension-on-imported-type.test.ts(fails on main, passes here, kernel and wasm extraction): same-package call, imported-by-name and.*calls, an unimported extension (no edge), an extension on a differentModifiertype (no edge), and Compose's own member (no edge). Dropping either check yields a wrong edge in the test. Full suite on Linux passes; the Kotlin suites and #2196'sjava-outside-imports.test.tspass withCODEGRAPH_KERNEL_EXPECT=1.Measurements
Three Android apps (132–793 JVM files): edges identical before and after (0 added / 0 removed) — they call their own extensions through instances only, which #2196 never blocked. So this is a precision-safe fix for the
Type.extension()shape rather than a measured win on these repos.The visibility check follows the
kotlinExtensionInScopeidea from @mixxer's #1948 discussion; thanks!🤖 Generated with Claude Code