Feature Request: Support Graph Query Languages for AST‑Based Code Analysis

[qdrddr]

Is your feature request related to a problem? Please describe.
Current AST tooling focuses on extracting individual symbols (nodes) but does not provide a way to explore the relationships between them (edges). When working with real codebases, it’s often more important to understand how functions depend on each other than to simply list them. Without graph‑style queries, it’s difficult to answer questions like “Who calls this function?”, “What is the full call chain?”, or “Which functions are unused?”

Describe the solution you'd like
Add support for querying the AST using graph query languages such as Cypher, SPARQL, or GraphQL.
By exposing the AST as a graph—functions as nodes, calls as edges—developers could run structural queries, build call graphs, and analyze dependencies directly.

Describe alternatives you've considered

• Manually walking the AST and building a call graph in custom code
• Using external tools like ast-grep or static analyzers, which still don’t provide graph‑query semantics
• Exporting AST data into a separate graph database and querying it there (adds unnecessary complexity)

Additional context

Example Code

def load_data():
    return fetch_from_db()

def fetch_from_db():
    return parse_record("raw")

def parse_record(x):
    return x.upper()

def main():
    data = load_data()
    print(data)

Dependency chain: main → load_data → fetch_from_db → parse_record

Graph Query Examples

When a user needs to find all callers of parse_record:

Cypher Examples

MATCH (caller)-[:CALLS]->(callee {name: "parse_record"})
RETURN caller;

SPARQL Examples

PREFIX code: <http://example.com/code#>

SELECT ?caller
WHERE {
  ?caller code:calls ?callee .
  ?callee code:name "parse_record" .
}

GraphQL API Examples

query {
  functions(where: { calls: { name: "parse_record" } }) {
    name
  }
}

Use Cases

Query	Purpose
Which functions does load_data call?	Inspect outgoing edges (dependencies).
Which functions call parse_record?	Reverse edges to find dependents.
Show the full call chain starting from main()	Traverse the graph (DFS/BFS).
Which functions are leaf nodes?	Identify functions with no outgoing calls.
Which functions are unused?	Identify nodes with no incoming edges.

Why This Matters

• Enables richer static analysis
• Supports knowledge‑graph workflows
• Helps with refactoring, dead‑code detection, and architecture mapping
• Aligns with modern developer expectations around structural search

[probelabs]

Thank You for This Feature Request!

Hello @qdrddr, and thank you for this well-articulated feature request! You've clearly identified a gap in current code analysis tooling, and I appreciate the detailed examples and use cases you've provided.

---

What I Understand From Your Request

You're proposing that Probe add support for graph query languages (Cypher, SPARQL, GraphQL) to enable structural queries on code relationships, such as:

• Finding callers/callees of functions
• Traversing call chains
• Identifying unused code (leaf nodes with no incoming edges)
• Building dependency graphs

This would treat the AST as a graph where functions are nodes and calls are edges, enabling richer static analysis.

---

Current State of Probe

Based on my exploration of the codebase, Probe currently provides:

1. AST-based symbol extraction via tree-sitter - can find function/class definitions and extract their full bodies
2. Pattern matching via ast-grep integration - can find structural patterns like fn $NAME($$$) $$$BODY
3. Symbol resolution - can find qualified symbols like Cache.get or DataProcessor.process
4. Text-based search with ripgrep - fast keyword/term matching

What Probe does NOT currently have:

• Cross-file call graph construction
• Edge relationship tracking (who calls whom)
• Graph-based query semantics
• Reverse dependency analysis (find all callers)

---

Assessment

Aspect	Evaluation
Category	Feature
Priority	Medium
Complexity	Complex
Scope	Major architectural addition

This is a significant feature request that would require substantial new infrastructure:

1. Call graph construction - parsing all files to extract function definitions AND call sites
2. Graph storage/indexing - efficient storage of node/edge relationships
3. Query language integration - parser and executor for Cypher/SPARQL/GraphQL
4. Cross-file analysis - resolving calls across file boundaries

---

Clarifying Questions

To help scope this feature appropriately, I have a few questions:

1. Query Language Preference: Among Cypher, SPARQL, and GraphQL, do you have a strong preference? Each has different tradeoffs:

   • Cypher: Most intuitive for graph traversal, but requires Neo4j-style semantics
   • SPARQL: Standards-based (RDF), but verbose
   • GraphQL: Familiar to many developers, but designed for API queries rather than graph traversal

2. Scope Granularity: Should the graph include:

   • Only function-to-function calls?
   • Method calls on classes/structs?
   • Dynamic dispatch (interface method calls)?
   • External library calls?

3. Incremental vs. Full Analysis: Would you expect:

   • A one-time full-repo graph build (slower, complete)?
   • Incremental updates as code changes?
   • On-demand analysis for specific queries?

4. Language Support Priority: Which languages would you want supported first? (Probe currently supports 16+ languages via tree-sitter)

---

Potential Implementation Paths

Option A: Built-in Graph Layer

• Add a call graph builder to the Rust core
• Store relationships in an in-memory graph structure
• Implement a simplified query DSL (not full Cypher, but graph-traversal focused)

Option B: Export + External Tool Integration

• Add an --export-graph command to output call relationships as JSON/GraphML
• Users can then load into Neo4j, memgraph, or other graph databases for querying

Option C: LLM Script Integration

• Leverage the existing LLM Script engine to orchestrate multi-step call chain analysis
• Use existing search/extract tools programmatically to build call graphs on-demand

---

Next Steps

This feature aligns well with Probe's mission of enabling deeper code understanding. The team will evaluate this request against the roadmap and community interest.

In the meantime, you might be able to achieve some of these goals using Probe's existing tools:

# Find all calls to a function
probe search "parse_record(" ./src

# Find function definitions
probe query "def $NAME($$$): $$$BODY" ./src --language python

# Extract a specific function and its context
probe extract ./src/main.py#parse_record

For complex call chain analysis, you could also use Probe's LLM Script to orchestrate multi-step analysis programmatically.

---

References:

• probe/ARCHITECTURE.md – System architecture overview
• probe/src/extract/symbol_finder.rs:318-566 – Symbol resolution implementation
• probe/src/query.rs:100-216 – AST pattern matching via ast-grep
• probe/src/language/language_trait.rs:4-44 – Language implementation trait
• probe/docs/llm-script.md – LLM Script orchestration engine

---

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>

[qdrddr]

1. Cypher could be simpler than others. Though I do not have a preference. GraphQL, even though it is API only, could still very much be used. So I want to leave this design decision to the development team for this architectural decision.
2. Scope Granularity should be as much granular as possible to give precision and details for calls and dependencies across classes, methods, libraries, constants, etc.
3. I would expect in-memory AST graph querying, so no synchronizations (and therefore no lags in code indexing). The indexing and import/export in practice for development is super not usefull and should be avoided at any cost, because it will make all the hard effort in vain since users would not adopt this approach.
4. I would propose starting with the most widely used popular languages, such as Python, TypeScript, Rust, etc.
5. The query capabilities should be available to both users manually or with LLM programmatically via the query MCP tool.

[buger]

@qdrddr hi! Thats work in progress, however AST itself does not have knowledge about dependencies. AST is just parsed file, no more then this. If we wanna true Graphs, you have to use LSP - language server integration. The job of LSP to parse whole codebase, index it, and know all the language rules, so you can actually provide things like "find all references" or "find all usages" - what you can do in VS Code or similar (because they depend on LSP too).

This PR adds LSP support - needs some work on its stability. But it adds the full LSP integration, storing it in SQLite DB, and allow querying it. #103

[qdrddr]

can be useful for this project
https://github.com/CategoricalData/hydra/tree/main/hydra-ext/demos/graphql-json

[Koolerx]

i'd recommend taking a look at https://github.com/abhigyanpatwari/GitNexus/