Builtin-name list is checked by every language, so Go/Rust/Ruby/PHP/C/C++ lose real call edges — but it also hides wrong ones (follows #2296) #2313

When graphify links a call to its definition, it skips any callee whose name is in _LANGUAGE_BUILTIN_GLOBALS. That list mixes builtins from Python, JS, Swift and others, and every language checks it. So a Go method named set gets no incoming calls, because set is a Python builtin.

The obvious fix is to give each language its own list. Doing only that would make things worse: on a real Go repo, most of what the list blocks today are wrong edges that should stay blocked. Details below.

Example

From 3x-ui. One file, one struct, two methods:

// internal/web/job/node_traffic_sync_job.go
type atomicBool struct { mu sync.Mutex; v bool }

func (a *atomicBool) set()          { ... }   // L63
func (a *atomicBool) takeAndReset() { ... }   // L71

j.structural.set()            // L147
j.structural.takeAndReset()   // L234
j.structural.set()            // L379

(*atomicBool).set            incoming calls = 0   ← called twice
(*atomicBool).takeAndReset   incoming calls = 1   ← correct

The two methods are on the same struct, in the same file, and are called the same way. The only difference is that set is on the list.

Where the check runs

graphify/extractors/go.py:395       (Go builtins are checked first since #2296)
graphify/extractors/rust.py:372
graphify/extractors/elixir.py:203
graphify/extractors/engine.py:4158  Ruby, C#, Java, Kotlin, PHP, Python, JS/TS, Swift, C, C++
graphify/extract.py:5305            shared cross-file pass, all languages

At each extraction site the check blocks both the in-file match and the hand-off to cross-file resolution. At extract.py:5305 it runs before import evidence is looked at, so a name that is explicitly imported is still dropped.

How widespread

I made a two-file repo for each language: file a defines a name and file b calls it from another file. I tested 29 common names, plus a made-up control name zqxwidget.

Changing one letter makes each name resolve (len → lenx, Error → Errorz), so the list is the cause. Python is not affected because it resolves names earlier through symbol_resolution, even though Python builtins are the biggest part of the list.

Why splitting the list alone is wrong

On a 466-file Go repo, turning the list off adds 45 edges:

Six types in that repo define Error(). Without type information graphify can't tell which one err.Error() calls. If those 31 calls were linked by name, one node would collect calls that belong to six types. That is the problem #2296 removed. Today Error is blocked only because JS has a global Error. The reason is wrong but the result is right. Split the list per language and those 31 wrong edges come back in every Go repo.

The TS/JS side of the same repo has 512 blocked edges. Almost all of them are names with several definitions (set 260 edges across 6 definitions, map 158 across 3, filter 39 across 2). Every single-definition case I checked (next, range, iter) was inside a minified vendor bundle.

Suggested order

1. When linking a bare name across files, refuse if the repo has more than one definition with that name. This applies whether or not the name is on any list. disambiguate_ambiguous_candidates does something close for the ambiguous case, and this would be the default.
2. Then split the list per language. Error stays blocked for the right reason and set comes back.
3. Where possible, decide by the shape of the call instead of by name lists. fix(go): filter Go predeclared functions from call-target resolution #2296 checks whether the callee is a bare identifier, which is safe at any stage.

Not checked

• Real-repo numbers exist only for Go and TS/JS. Rust, Ruby, PHP, C, C++, C# and Java were confirmed only on the synthetic repos.
• Elixir was not measured, because the control name doesn't resolve there either.
• In-file matches were spot-checked only for Go and Rust.
• I only checked Go for the opposite case: a language whose builtins are on no list and end up getting wrongly linked.

Measured on upstream/v8 at ecfcd16 plus the #2296 head.