feat(callgraph): C call graph builder#674
Merged
shivasurya merged 1 commit intomainfrom May 3, 2026
Merged
Conversation
shivasurya
added
enhancement
SafeDep Report Summary
No dependency changes detected. Nothing to scan. This report is generated by SafeDep Github App |
Code Pathfinder Security Scan
No security issues detected.
Powered by Code Pathfinder |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #674 +/- ##
==========================================
- Coverage 85.28% 85.28% -0.01%
==========================================
Files 182 183 +1
Lines 26399 26545 +146
==========================================
+ Hits 22515 22639 +124
- Misses 3023 3038 +15
- Partials 861 868 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This was referenced May 2, 2026
Owner
Author
This was referenced May 3, 2026
Owner
Author
Merge activity
|
shivasurya
changed the base branch from
shiva/cpp-type-inference
to
graphite-base/674
Add BuildCCallGraph — a four-pass algorithm that produces a
*core.CallGraph for C projects:
Pass 1 Index every C function_definition under "<relpath>::<name>"
and ensure the FQN appears in the module registry's
FunctionIndex for cross-file resolution.
Pass 2 Register explicit return types with the type engine
(skipping void) and emit ParameterSymbol entries for every
named parameter.
Pass 3 Walk the parser-emitted edges (function_definition →
call_expression) to extract one CallSiteInternal per call,
deterministically and without a second AST traversal.
Pass 4 Resolve targets in a definition-preferring order:
same-file definition → global definition → same-file
declaration → declaration reachable through #include "...".
Resolved sites add an edge; unresolved sites are recorded
as CallSite{Resolved:false} so external/stdlib calls remain
visible to rule writers.
The result merges cleanly into a unified graph via the existing
MergeCallGraphs since C FQNs ("src/main.c::main") share no namespace
with Python, Go, or Java.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
shivasurya
force-pushed
the
shiva/cpp-c-call-graph
branch
from
3055d72 to
d55e6cc
Compare
shivasurya
added a commit
that referenced
this pull request
May 3, 2026
## Summary
Adds `BuildCppCallGraph` — the four-pass C builder plus three C++-specific resolution paths exercised in Pass 4. Plain free-function calls fall through to `resolveCCallTarget`, making the C++ builder a strict superset of the C one.
| Step | Resolves |
|---|---|
| 1 | Qualified call (`ns::func`, `Class::staticMethod`) — direct `NamespaceIndex` lookup |
| 2 | `this->method()` — caller's enclosing class derived via byte-range containment |
| 3 | Method on typed receiver — receiver type from the type engine, method on that class |
| 4 | C-style fallthrough — definition-preferring lookup shared with the C builder |
### Receiver type normalisation
`obj.method()` calls drive resolution through the receiver's declared type. Before the lookup, the type string is normalised: `const`, `volatile`, and pointer/reference suffixes (`*`, `**`, `&`, `&&`) are stripped so `Dog*`, `const Dog&`, and `Dog **` all reduce to `Dog`.
### Class member tracking (Pass 2)
- Class method return types registered on the type engine for both definitions and declarations — header-only inline declarations still seed receiver-typed resolution.
- Field types extracted from `field_declaration` nodes for future field-chain resolution (`obj.field.method()`).
### Method-to-class association
Same byte-range containment used in PR-05 (`BuildCppModuleRegistry`): for each method, find the smallest class declaration whose `[StartByte, EndByte)` range contains the method's start byte. Nested classes (`class Outer { class Inner { ... }; };`) resolve to the innermost match. The builder doesn't depend on parser-internal context tracking, so it stays composable across future parser refactors.
## Test plan
- [x] `go build ./...`
- [x] `go test ./...` — full suite green
- [x] `go vet ./...`
- [x] `golangci-lint run ./graph/callgraph/builder/` — 0 issues
- [x] Coverage on `cpp_builder.go` lines: ~93%
- [x] Spec scenarios covered:
- Namespace-qualified call (`mylib::process`)
- Static method via NamespaceIndex (`Socket::create`)
- Method on typed receiver (`dog.speak()` where `dog: Dog*`)
- `this->method()` inside a method body
- Free-function fallthrough
- `printf` (stdlib) → unresolved with failure reason
- Receiver not in scope → unresolved (no panic)
- Method return type registered on the type engine; void dropped
- Field types registered on the type engine
- Receiver normalisation across pointer/reference/const/volatile/whitespace shapes
- Nested classes pick the innermost match
- Suffix match on namespaced classes (`Foo` → `ns::Foo::bar`)
- Merges cleanly into a unified graph
- Receiver binding with nil Type doesn't panic
- `this->method()` on a non-method caller falls through cleanly
- Header-only declarations still register class method return types
- Non-C++ nodes ignored (mixed-language safety)
## Stacked on
`shiva/cpp-c-call-graph` (#674)
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
Adds
BuildCCallGraph— a four-pass algorithm that produces a*core.CallGraphfor C projects, ready to merge into the unified graph alongside Python/Go.function_definitionunder\"<relpath>::<name>\"and ensure the FQN is also inregistry.FunctionIndexvoid) and emitParameterSymbolentries for every named parameterfunction_definition → call_expression) to extract oneCallSiteInternalper call — no second AST traversalCallSiterecordsResolution order (Pass 4)
.c); deterministic and independent of include state.registry.FunctionIndex[name]for an FQN whose call-graph entry is a definition. Handles cross-.ccalls.#include— last resort so externs handed off to another translation unit still surface as edges.Calls that don't match any source produce a
CallSite{Resolved: false, FailureReason: \"external_or_unresolved\"}— stdlib calls (printf,malloc) and unknown function pointers remain visible to rule writers without polluting the edge set.Design notes
parseCCallExpressionadds an edge from the enclosing function to the call node. The builder walksOutgoingEdgesof each indexed function instead of doing byte-range containment, keeping Pass 3 deterministic and trivially testable.Metadata[\"is_declaration\"]=trueon prototype/extern decls.isDeclaration()reads that key with a typed assertion so non-declaration nodes (no metadata) fall through correctly.process → process) are emitted as-is; the call graph already deduplicates viaAddEdge..cfiles map to disjoint FQNs.FunctionIndexso callingBuildCCallGraphafterBuildCModuleRegistryis idempotent.Test plan
go build ./...go test ./...— full suite greengo vet ./...golangci-lint run ./graph/callgraph/builder/— 0 issuesc_builder.golines: ~89.6%main()→add()edge.cdefinition preferred over.hdeclaration#includefallbackprintf(stdlib) recorded asResolved:falsewith failure reason.cfiles (file-scope statics)voidreturns dropped.cglobal lookup works without an#includeStacked on
shiva/cpp-type-inference(#673)