fix(parser): emit call edges for generic calls in Scala, Go, C++ and Swift

[zzet]

Fixes #537.

Four more extractors share the blind spot found in #534: a call query that pins the callee to a plain identifier node drops every call spelling explicit type arguments, because those grammars wrap the callee in a different node. The call emits no edge at all — not an unresolved stub — so query callers answers total_edges: 0 with the likely_unused caveat, and a resolution failure is indistinguishable from dead code.

This is a recurring class here: rust.go carries a note that the turbofish version of it cost 5,301 unrecorded call sites.

Every shape below was pinned by dumping the real parse tree and confirmed by running the real extractor before and after — no query was fixed on inference. One commit per language, each with its own extractorVersions bump so already-indexed files re-extract instead of keeping the edge-less graph.

Scala — generic_function

extractCall switched on the callee and handled only identifier / field_expression, falling through to default: return. Any callee with type arguments is wrapped:

(call_expression function: (generic_function function: (identifier) type_arguments: (…)) arguments: (…))

f[T](), obj.m[T](x) and Future[Int] { … } all emitted nothing. Unwrapping to the real callee lets the two existing cases apply unchanged.

Go — two mechanisms, not one

The patterns pinned function: to (identifier) / (selector_expression). A Go call with one type argument matches neither, via two different routes — fixing only the obvious one leaves half the calls missing:

Written	Parses as
Zero[int](), obj.M[int]()	function: (index_expression …)
OneArg[int](1), obj.N[int](1)	type_conversion_expression — not a call at all

Two or more type arguments were never affected (F[string, int](a, b) keeps a plain callee with a sibling type_arguments field), which is why the gap looked like it didn't exist.

Both shapes are genuinely ambiguous in the grammar. An index_expression callee is also how handlers[key]() parses, and a conversion to a generic type is spelled exactly like a one-argument generic call. Widening therefore emits an unresolved stub for those too.

That is safe for a reason specific to Go rather than luck: a package-scope name is a func, a var or a type — never two of them. A stub named after a variable or a type finds no function candidate and stays unresolved, and an unresolved target is a placeholder reverse walks ignore. TestResolveGo_IndexAndConversionDoNotBindWrongly asserts no call edge in that fixture ever lands on a non-callable node, and its sibling asserts a real cross-file generic call still resolves.

C++ — three of five callee shapes were missing

The query matched a bare identifier and a field_expression with a field_identifier. C++ has five:

• generic<int>() → function: (template_function …)
• obj.m<int>() / ptr->m<int>() → field: (template_method …)
• ns::helper() / std::move(x) → function: (qualified_identifier …)

The last is not about templates and is the larger loss: every namespace-qualified free call in the language was dropped, so a codebase that qualifies consistently recorded almost no free calls at all. rust.go already carries the equivalent scoped_identifier pattern; C++ now matches it.

Swift — two losses, the second much larger

Adding type arguments reroutes any Swift call away from call_expression entirely:

constructor_expression
  user_type "obj.doThing<Int>"
    type_identifier "obj"
    type_identifier "doThing"
    type_arguments "<Int>"
  constructor_suffix "()"

lowerGeneric<Int>(), obj.doThing<Int>() and MyType<Int>(x: 1) all became constructor_expression, which nothing in the query matched. The constructed type's own type_identifier children give the dotted path back; the ones nested inside type_arguments are the arguments and are excluded.

The second loss was not in the issue. The member branch was gated to factory chains only, on the stated belief that the bare-identifier pattern stayed "authoritative for ordinary obj.method()". It never was — that pattern needs a simple_identifier as a direct child of the call, and a member call nests it under a navigation_expression. So every plain obj.method() and self.method() emitted no edge either:

  calls Runner.run -> unresolved::free        line=8   ✓ free call
  (nothing)                                   line=9   ✗ h.work()
  (nothing)                                   line=10  ✗ self.free()
  calls Runner.run -> unresolved::*.work      line=11  ✓ Helper().work()  (factory chain)

Swift was recording free calls and factory chains and nothing in between. Removing the gate restores what every other language already does, and the generic fix would have been incoherent without it — o.doThing<Int>() resolving while o.doThing() did not.

Verified clean, and why

Probed the same way and left alone: typescript (.ts + .tsx), java, kotlin, rust, dart, c, php. In TS and Java the type arguments are a sibling field of the callee; in Kotlin they live inside call_suffix; Dart's sit inside argument_part; C and PHP have no generic call syntax.

Verification

go test ./internal/... passes in full; golangci-lint reports 0 issues. Each language's test pairs the plain and generic spellings of every call shape and asserts they behave identically — the property that was actually violated, and the one that makes the regression hard to reintroduce quietly.

Note for merging

Touches the same extractorVersions map as #536, so whichever merges second will want a one-line conflict resolution. The two PRs are otherwise independent.

[zzet]

Closing the loop on the one claim in this PR that was an argument rather than a measurement.

Removing the Swift member-call gate was justified by "every other language emits member calls, so Swift was the outlier" — but the gate's own comment existed to stop the graph being flooded, and there was no Swift corpus in the repo to check against. There is one off-repo: 78 files of real iOS app code plus vendored CocoaPods sources. Measured at 3c5fd67 (the commit this PR merged onto) and at the merge result:

corpus	files	call edges	calls/file	member calls	member share
Swift, before	78	1767	22.7	97	5%
Swift, after	78	3724	47.7	2049	55%
Go internal/resolver	78	3978	51.0	863	22%
Go internal/mcp	78	7955	102.0	1820	23%

Two things fall out.

The gate was hiding ~95% of Swift member calls. Only 97 of 2049 survived it — the factory-chain ones. A 5% member share was never plausible for Cocoa code, where message passing is the dominant idiom; the 55% after the fix is what iOS code actually looks like.

It is not flooding. At 47.7 call edges per file Swift now sits below both Go corpora (51.0 and 102.0). Node counts are unchanged at 2455 — this recovers edges that were always implied by the source, and lands Swift in the same density band as a language nobody considers noisy.

Method: extract each file with the real SwiftExtractor and count EdgeCalls, unresolved::*. prefix for the member subset. Same file set and same 78-file cap on both sides.