fix(scala): classify companion objects as module; prefer type defs for extends/implements resolution - #1826
Open
htarnacki wants to merge 1 commit into
Open
Conversation
The Scala trait + companion object idiom puts two same-named symbols in one file. Both were indexed as kind 'class', so an 'extends X' reference tied between the trait and its companion and the winner was arbitrary. When the companion won, every subtype was detached from the trait's inheritance chain, and impact analysis on a widely-used trait stopped at depth 1. - classify Scala object_definition as 'module' (a singleton value, not a type - 'extends' can never target it) - add 'module' to the classifyClassNode contract and handle it in the extractor dispatch - in name matching, bias extends/implements references toward actual type definitions and penalize 'module' candidates, so the trait wins the tie deterministically Regression test: trait + companion in one file, subclass in another - the extends edge must land on the trait and impact must reach the subtype through it.
htarnacki
force-pushed
the
fix/scala-companion-object
branch
from
September 10, 2026 07:19
9a2f10f to
1498217
Compare
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
1 participant
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.
Fixes #1824
Problem
Scala
objectdefinitions were indexed as kindclass. In the trait + companion object idiom the trait and its companion share both name and file, soextends Xreferences resolved by name matching tied between the two candidates. When the companion won, theextendsedge landed on the singleton and every subtype was detached from the trait's inheritance chain —codegraph impacton the trait stopped at depth 1.Changes
scala.ts,tree-sitter-types.ts,tree-sitter.ts): classify Scalaobject_definitionas kindmoduleinstead ofclass. A Scalaobjectis a singleton value, not a type, so it can never be a validextendstarget.name-matcher.ts): for inheritance references (isInheritanceRef), penalizemodulecandidates infindBestMatch, so the trait wins the tie deterministically.modulestays inSUPERTYPE_TARGET_KINDS(fix(resolution): constrain inheritance/import reference target kinds (#1536, #1537) #1796) — it is still eligible (Rubyinclude, TS namespaces), just ranked below a same-named type.resolution.test.ts): trait + companion in one file, subclass in another — asserts theextendsedge targets the trait (none on the module) and thatgetImpactRadiusfrom the trait reaches the subtype.[Unreleased].Verification
On a production Scala codebase (~900k nodes),
codegraph impact -d 10 <widely-mixed-in trait>went from 28 to 186 affected symbols after this change (combined with #1825).Rebased on current
main(post #1796).extraction,resolution,graphandframeworkssuites green on Node 24 (FTS5); the remaining engine-suite failures in my environment are identical on a cleanorigin/maincheckout (nodist/viewer, daemon/MCP process tests).