Low call-edge density in graph output (~0.57 calls/function on Swift sample)

[cadespivey]

Summary

On a ~3,854-function Swift codebase, the graph exposes only ~2,192 calls edges — a ratio of ~0.57 calls per function. That's sparse for a running application and limits the usefulness of any downstream analysis that needs intra-process call-chains (blast-radius transitive closure, dead-code, find-callers).

Framing this as an observation / discussion rather than a definite bug — I don't have a good baseline for what the expected ratio "should" be across languages, and Swift's dynamic dispatch + protocol-witness indirection makes static call-graph extraction legitimately hard. But flagging it because several downstream features appear to suffer from the sparsity (see also #138 on transitive closure).

Not Swift-specific in principle — the question of "how many call edges do you capture per function, and what's known to be missed" applies to every language you parse.

Environment

• supermodel 0.6.10, macOS arm64
• Swift (SwiftPM multi-module app, ~382 files)

Data

Relationship-type histogram from the graph JSON (fresh supermodel analyze):

belongsTo              4012
defines_function       3854   ← decl→container, one per function
calls                  2192   ← THE call graph
declares_class         1211
imports                 990
contains_file           400
child_directory         143
defines                  79
partOf                   16
...

calls / Function nodes = 2,192 / 3,854 ≈ 0.57 calls per function.

Why it matters

• audit impact-analysis table populates directDependents but Impact analysis: transitiveDependents always 0 while directDependents is populated #138's transitive-closure zero is likely downstream of sparse call edges.
• supermodel focus Sources/.../DataStoreImpl.swift (a 4,069-line file with 174 declarations) returns only imports — no callers, no callees. Could be a per-file slicing issue, but it's at least consistent with "the file has no outgoing call edges in the graph."
• find <symbol> returns declarations but no usages/callers.

Questions for maintainers

1. Do you publish a target call-edge density (calls/function) per language that you consider "healthy" extraction? If I fall below it, I know the parser underperformed on my codebase.
2. Are intra-file / intra-type calls expected to be represented as calls edges, or only cross-file? The sparse count would be consistent with "cross-file only."
3. For Swift specifically: is the call-graph extractor AST-only, or does it use any type resolution (SourceKit / swift-syntax + semantic) to handle protocol dispatch and generic calls? AST-only would plausibly explain a low ratio.

Happy to provide the cached graph JSON if it helps triage.

[drQedwards]

PR #136 handles some new ways to consider the edges with the tools. That would add some discussion on what those would show in terms of number perhaps?

[greynewell]

Thanks for the detailed report and well-framed questions — this is genuinely useful feedback. Here's what we found after digging into the call graph extraction pipeline:

Answers to your three questions

1. Target call-edge density per language

We don't publish a target ratio, and after investigating the Swift case we think 0.57 calls/function is plausible (not a sign of a broken extractor) given the limitations below. That said, we agree it's a useful signal — we'll consider adding it to the analyze output as a diagnostic.

2. Are intra-file / intra-type calls captured?

Yes — intra-file calls are captured. The extractor checks same-file matches first before looking at imported files. So the sparsity is not explained by "cross-file only" coverage.

3. Is the Swift call-graph extractor AST-only?

Yes, it is AST-only. The pipeline is:

• tree-sitter parses Swift source to extract function/method definitions
• Regex patterns scan the raw source to extract call sites (the pattern for Swift is the generic \b([a-zA-Z_][a-zA-Z0-9_]*)\s*\( — Swift has no explicit entry in the per-language configuration)
• Name resolution is import-scoped: a call site in file A is matched against functions in files that A explicitly imports

There is no SourceKit / swift-syntax semantic integration, so protocol witness dispatch, generic specialization, and other type-directed calls are not resolvable statically.

Why 0.57 is expected for a protocol-heavy Swift codebase

The main sources of missed edges:

• Trailing closures — collection.filter { $0 > 0 } has no (, so the regex doesn't fire
• Protocol dispatch — calls through a protocol type can't be resolved to a concrete implementation without type information
• SwiftPM module boundaries — cross-module calls require the import to be detected at the file level; if import ModuleName isn't matched as a file-level import, those call targets are invisible
• Initializer calls — MyClass() is syntactically identical to a function call and is captured, but resolves correctly only if the type name matches a known declaration

For a Swift app that leans heavily on protocol-oriented design and closures (common in SwiftUI / Combine codebases), a ratio in the 0.4–0.8 range is consistent with what static AST analysis can recover without a compiler frontend.

What we're not changing (and why)

Integrating SourceKit or swift-syntax semantic resolution would dramatically improve the ratio but is a large undertaking and outside the current scope. Trailing-closure detection via an additional regex is feasible but would add noise (many trailing closures pass functions as arguments rather than calling named functions).

Closing this as a known limitation rather than a bug. If the sparsity is causing concrete downstream problems beyond what #138 and #139 addressed, please open a new issue with specifics and we'll revisit.