fix: Symbol.parameters/return_type extraction for Kotlin and Dart - #41
Open
pradeepmouli wants to merge 2 commits into
Open
fix: Symbol.parameters/return_type extraction for Kotlin and Dart#41pradeepmouli wants to merge 2 commits into
pradeepmouli wants to merge 2 commits into
Conversation
Symbol.parameters/return_type were empty for all Kotlin functions. Root cause, verified against tree-sitter-kotlin-ng's real node-types.json: function_declaration has no "parameters" or "return_type"/"result" named fields at all -- the parameter list (function_value_parameters) and the return type (a bare `type` node) are both positional children, structurally unreachable via child_by_field_name regardless of what field-name string is tried. Extended extract_entities's existing capture-name-keyed extraction idiom (already used for docstring/decorator/route.* fields) with two new optional captures, @func.params/@method.params and @func.return_type/@method.return_type, preferred over the existing field-name fallback when a language's query provides them. Wired up for Kotlin only in this commit -- zero changes to any other grammar, whose queries simply never provide these captures, so the fallback preserves their exact current behavior (regression-covered by the pre-existing Python parameters/return_type tests still passing unchanged).
Symbol.parameters/return_type were empty for all Dart functions and methods. Root cause, verified against tree-sitter-dart's real node-types.json: function_signature genuinely has "parameters"/ "return_type" named fields, but they live one level below the captured @func.def/@method.def node (through function_declaration's "signature" field for plain functions), so extract_child_text's direct child_by_field_name lookup on the outer node never sees them. For methods specifically it's worse -- method_signature has zero named fields at all, so there's no field-name path to the answer regardless of nesting depth, not just a wrong-node problem. Uses the @func.params/@method.params/@func.return_type/@method.return_type capture mechanism added for Kotlin in the previous commit -- this commit is .scm-only, no further Rust changes. Constructor signatures already worked via their own direct name+parameters fields and are unchanged, covered by a dedicated regression test. Field order in both the .scm patterns and the unit tests' inline queries is return_type/name/parameters, matching tree-sitter-dart's actual child order (return_type: (type) appears before name: and parameters: in the concrete tree) -- discovered empirically while debugging: tree-sitter's query matcher is order-sensitive across sibling field-qualified patterns even when each is field-name qualified, so declaring them in a different order (as in the original plan's tests) silently drops the return_type capture with no error, just a None result.
pradeepmouli
requested review from
johnintuit,
murari316 and
sandeep-mewara
as code owners
July 29, 2026 18:23
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.
Summary
Symbol.parameters/return_typeare populated at tree-sitter extraction time viaextract_child_text(node, "parameters"/"return_type", source), which callschild_by_field_name. This works correctly for 11 of 14 languages this project's SCIP indexers cover, but is structurally broken for Kotlin and Dart — verified against each grammar's actualnode-types.json, not assumed:tree-sitter-kotlin-ng'sfunction_declarationnode has noparameters/return_typenamed fields at all — the parameter list (function_value_parameters) and return type (a baretypenode) are both positional/unnamed children, structurally unreachable viachild_by_field_nameregardless of what field name is tried.parameters/return_typelive one level down on a nestedfunction_signaturenode (reached viafunction_declaration'ssignature:field), not on the captured node directly. Methods are worse —method_signaturehas zero named fields at all, soparametersis unreachable there for any method. Constructors already work correctly (constructor_signaturehas directname+parametersfields) and are unaffected.Fix
Extended
extract_entities's existing capture-name-keyed extraction idiom (already used fordocstring/decorator/route.*fields incrates/infigraph-core/src/extract/entities.rs) with two new optional capture names:@func.params/@method.paramsand@func.return_type/@method.return_type. When a language's.scmquery provides these, they're preferred over the existingchild_by_field_namefallback; when a language doesn't provide them (the other 11+ languages), the fallback is used exactly as before — zero behavior change for anything already working.Wired up for Kotlin and Dart via their own
.scmfiles (crates/infigraph-languages/languages/{kotlin,dart}/entities.scm) — no Rust code specific to either grammar, and no changes to any other language.One non-obvious gotcha hit and fixed during Dart's implementation: tree-sitter's query matcher is field-order-sensitive across sibling field-qualified patterns in a single query — it matches in the same relative order the fields are written in the query text. Dart's actual grammar (
function_signature) declaresreturn_typebeforename/parameterssyntactically; declaring the query in the more intuitivename → parameters → return_typeorder silently drops thereturn_typecapture with zero error output. The landed.scmusesreturn_type → name → parameters, matching the grammar's real order, with an explicit comment explaining why — verified directly againsttree-sitter-dart0.2.0'sgrammar.js.Test plan
cargo test -p infigraph-core --lib extract::entities— 44/44 pass (34 pre-existing + 2 new Kotlin + 3 new Dart, incl. a constructor regression guard)cargo fmt --all -- --check— cleancargo clippy -p infigraph-core --all-targets -- -D warnings— clean🤖 Generated with Claude Code