Expose resolved method calls as a CALLS edge#910
Open
paracycle wants to merge 1 commit into
Open
Conversation
cc553f6 to
8714ea8
Compare
7c184a1 to
6a12d7d
Compare
57c979c to
f99fc2c
Compare
6a12d7d to
2eaa2d6
Compare
f99fc2c to
fcbbf98
Compare
2eaa2d6 to
557b811
Compare
fcbbf98 to
0206dbe
Compare
Add a `CALLS` relationship (`Document` → `Method`) that maps method
references to the method declarations they resolve to, for calls whose
receiver type is statically known:
- a constant receiver (`Foo.bar`), resolved through the receiver's
singleton-class ancestry, and
- an implicit `self` call in a known scope.
The indexer already records these calls with a receiver-type name; the
schema resolves that name to a declaration and looks the method up along
its ancestry (matching the base name, since method members are keyed
`name()` while call sites record `name`). Calls with a dynamic/unknown
receiver carry no receiver and are intentionally not represented — those
would require type inference.
This makes call-graph queries possible, e.g. callers of a method:
`MATCH (d:Document)-[:CALLS]->(m:Method {unqualified_name: 'bar()'}) RETURN d.name`.
557b811 to
5d58c11
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
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.
Goal
Expose method calls in the Cypher graph, resolved to the method declarations they target — so the graph can answer call-graph questions, not just definition/inheritance ones.
What it adds
A new relationship type:
It maps a file's method references to the method declaration each one resolves to, for calls whose receiver type is statically known:
Foo.bar), resolved through the receiver's singleton-class ancestry (where class methods live), andselfcall in a known scope (e.g. calling a sibling method from inside an instance method).How it resolves
The indexer already records each call with the receiver type's name (the singleton-class name for
Foo.bar, the enclosing type for aselfcall). The schema:name()while call sites record the barename, so a direct id match doesn't work.Scope / non-goals
Calls with a dynamic or unknown receiver (
foo.baron a local, a method-chain result, etc.) carry no receiver from the indexer and are intentionally not represented — resolving them would require type inference. This edge covers the statically-resolvable subset only; it's best-effort (first match in ancestry order) rather than a guaranteed runtime target.The resolver currently lives in the cypher schema (consistent with how it already maps the graph); a future refactor could share a
Graph-level method resolver withquery.rs's completion path.Verification
cargo test -p rubydex query::cypher(20 tests, incl. resolution + reverse "who calls this" + that dynamic-receiver calls are excluded); clippy + fmt clean;--schemalistsCALLS; full gem suite green.