Instance calls through a variable receiver never resolve (all tags languages)

[stephane-segning]

Summary

On every tags-driven language (Java, TypeScript, Python), a method call through a variable
receiver — a.helper() — produces no calls edge at all. This is the most common call shape
in idiomatic code in all three languages, so the cross-file call graph is substantially incomplete
on real repositories.

The cause is a type/name confusion. callee.rs records the call's qualifier as the receiver
identifier text (a), while Callable::scope holds the declaring type name (A).
resolve::pick then compares them textually:

if let [only] = candidates {
    if let (Some(q), Some(scope)) = (qualifier, only.scope.as_deref())
        && q != scope
    {
        return Pick::None;   // <- "a" != "A", so the only real candidate is rejected
    }
    return Pick::One(only.node_id.as_str());
}

There is no type inference, so q equals scope only when the variable happens to be named exactly
like its type. In idiomatic code that is almost never true. The single-candidate branch — the easy,
unambiguous case — therefore rejects the one correct answer.

Note the direction of the failure: this is not "ambiguous, so drop" (the documented,
precision-favouring policy). There is exactly one candidate and it is correct, and it is
discarded anyway.

Reproduction

Verified against main, with no interfaces and no annotations involved:

// A.java
class A { int helper() { return 1; } }

// B.java
class B {
    void run() {
        A a = new A();
        a.helper();
    }
}

Call shape	calls edges
a.helper() — instance call via a variable	0
A.helper() — type-qualified	1
helper() — bare	1

The same holds for TypeScript and Python:

TS  : instance call via variable      0 calls
TS  : bare call                       1 calls
PY  : instance call via variable      0 calls
PY  : bare call                       1 calls

Why the test suite did not catch this

Every Java call site in tests/fixtures/java-repo/ is type-qualified (Util.caller(),
Widget.build()), this-qualified (this.size()), or bare (build()). Not one is an instance
call through a variable — so the committed golden is blind to the case, and has been since the
fixture was written.

container_repos does not catch it either: it asserts at least one calls edge and gets
hundreds, because this.-qualified and static calls still resolve. A count-based invariant cannot
distinguish "resolved most calls" from "resolved only the easy third of them".

Relationship to #5 and #1

Distinct bug, distinct fix.

• Trait methods without a default body are never extracted (no chunk, no graph node) #1 and Java interface methods: single-impl calls are dropped as ambiguous (the tags-path twin of #1) #5 are about ambiguity: two same-named candidates (a declaration and its
  implementation) with nothing to choose between them, so the call was dropped. Fixed by excluding
  declarations from the candidate set.
• This is about a single, unambiguous candidate being actively rejected by a comparison that
  cannot succeed.

The reproduction I originally wrote in #5 (g.greet() through an interface-typed variable) happened
to hit both bugs at once, which made #5 look like it covered this. It does not — that was a poorly
chosen example on my part, and #5 has been corrected.

Suggested direction

The qualifier is currently an untyped string doing two different jobs (type name vs. receiver
variable name). Options, roughly in order of increasing effort:

1. Distinguish the two at capture time — record whether the qualifier is a type-like or a
   value-like reference (Java/TS convention: capitalised identifier ⇒ type). Then only apply the
   q != scope rejection when the qualifier really is a type reference, and treat a value receiver
   as "no usable qualifier" — which falls through to the existing single-candidate resolution and
   the existing ambiguity policy when there are several. This is small and keeps the precision
   policy intact.
2. Minimal local type inference — track Type name = new Type(...) and declared parameter/field
   types within a file to map a receiver variable to its type. More precise, considerably more work,
   and still only intra-file.

Option 1 looks like the right first move: it converts a guaranteed-miss into the existing,
already-reasoned-about resolution path, without inventing type inference.

Whatever the fix, the fixtures need an instance-call-through-a-variable case in every tags
language, since their absence is what let this survive.

Provenance

Found independently and from opposite directions by two reviews on the same day: an adversarial
review of the #5 fix, and a Spring-support design spike that ran the unmodified extractor over a
realistic Spring fixture set and got zero calls edges — then isolated it to a two-class
fixture with no interfaces and no annotations, proving it is not framework-related. Reproduced a
third time here independently before filing.

[stephane-segning]

Reopening — this was closed as completed with no commit, no comment, and no fix. It is not fixed.

Re-verified just now against main at 293d12f, i.e. after #7 (the #5 fix) and #9 merged:

TS  : instance call via variable      0 calls
TS  : bare call                       1 calls
PY  : instance call via variable      0 calls
PY  : bare call                       1 calls

Java behaves identically — a.helper() through a variable still yields zero calls edges, while
A.helper() and bare helper() both resolve.

Nothing in #7 touches this. #7 changed Classifier::is_call_target (which definitions enter the
candidate set); this bug lives in resolve::pick's single-candidate branch, which rejects the one
correct candidate because the qualifier holds a receiver variable name and Callable::scope holds
a type name. #7 deliberately left resolve::pick alone and said so.

Please don't close this without a linked fix and a test — specifically a fixture with an instance
call through a variable receiver in each tags language, since the absence of exactly that shape from
the existing fixtures is what let this survive unnoticed in the first place.