C++ method calls to same-named classes in different files all resolve to the first definition

[Dshuishui]

Summary

For C++, a method call obj.method() is resolved by a global method-name lookup.
When two files each define a class with the same name and method, every caller
collapses onto the first matching definition, and the other file's method
receives no incoming calls edge. With distinct class names the same code
resolves precisely, so this only affects same-named classes across files.

Reproduction

Two files, each defining class Logger { void log(); } and a caller:

// a/svc.cpp
class Logger { public: void log() { int a = 1; } };
void useA() { Logger lg; lg.log(); }

// b/svc.cpp
class Logger { public: void log() { int b = 2; } };
void useB() { Logger lg; lg.log(); }

codegraph init
sqlite3 .codegraph/codegraph.db \
  "SELECT s.name, t.name, t.file_path FROM edges e
   JOIN nodes s ON e.source=s.id JOIN nodes t ON e.target=t.id
   WHERE e.kind='calls' AND s.language='cpp' ORDER BY s.name;"

Output — useB lives in b/svc.cpp but its call resolves to a/svc.cpp:

useA|log|a/svc.cpp
useB|log|a/svc.cpp

b/svc.cpp's Logger::log has no incoming calls edge.

Control: distinct class names resolve correctly

With class LoggerA in a/svc.cpp and class LoggerB in b/svc.cpp (callers
unchanged), the same query gives:

useA|log|a/svc.cpp
useB|log|b/svc.cpp

Expected

useB constructs a local Logger and calls .log(), so the call would resolve
to b/svc.cpp's Logger::log (each caller to its own file's definition).

Likely cause

In src/resolution/name-matcher.ts, resolveMethodOnType() looks up the method
by name globally (getNodesByName); when several definitions match
Logger::log, disambiguation by file path appears to be gated on preferredFqn,
which seems to be populated only for Java/Kotlin (from import hints). C++ call
sites have no such hint, so resolution falls through to the first match
(matches[0]).

Environment

• codegraph 1.1.0
• macOS (Darwin arm64)

[inth3shadows]

Reproduced on v1.1.6 (Linux). Minimal repro — two files, each with its own Logger::log:

// a/svc.cpp
class Logger { public: void log() { int a = 1; } };
void useA() { Logger lg; lg.log(); }
// b/svc.cpp
class Logger { public: void log() { int b = 2; } };
void useB() { Logger lg; lg.log(); }

After codegraph index, both call edges point at the first definition:

useA -> a/svc.cpp:3   (ok)
useB -> a/svc.cpp:3   (wrong — should be b/svc.cpp:3)

Root cause looks like resolveMethodOnType in src/resolution/name-matcher.ts: when a name has multiple matches, the file-disambiguation block only runs for preferredFqn and hardcodes .java/.kt:

if (matches.length > 1 && preferredFqn) {
  const ext = ref.language === 'kotlin' ? '.kt' : '.java';
  ...
}
return { ..., targetNodeId: matches[0]!.id, ... }; // C++ falls through to the first match

So any language without a preferredFqn path (C/C++ here) collapses every same-named method onto matches[0].

One possible direction: before the matches[0] fallback, prefer a match in the same file as the call site — strongest signal, and language-agnostic. Worth confirming it doesn't disturb the Java import-disambiguation case in #314 (where the target is intentionally in another file).

Happy to open a PR for this if that direction works for you — I have the repro and a candidate fix ready to validate against the existing test suite.

[colbymchenry]

Fixed in #1107 (squash-merged to main, ships in the next release).

Your diagnosis was exactly right — resolveMethodOnType only disambiguated multiple matches via the Java/Kotlin import FQN (#314), and every other language fell through to matches[0].

While confirming the fix I checked whether other languages were affected, and the same "pick the first-indexed definition, ignore the call site's file" pattern turned out to live in two sibling resolution paths as well — so the fix ended up broader than the original C++ instance-call repro:

Call shape	Affected
obj.log() — instance	C++
Logger.log() — class receiver	Python, TypeScript, Java, C#
Logger::log() — qualified	C++, Rust

All of these now prefer the definition in the caller's own file when a name is ambiguous, via a single shared preferCallSiteFile helper. Java/Kotlin calls that an import already pins to another file (#314) are unaffected — that disambiguation still runs first.

Thanks for the minimal two-file repro and the precise root-cause; it made this quick to run down. 🙏