Thanks for taking on the receiver false-positive problem. The exact head is security-clean and DCO passes, but it is not correct enough to merge:

1. Every full Unix/macOS/Windows test job fails deterministically at cp_enum_method_java: valid Java enum calls such as d.label() and d.isWeekend() become unresolved. This existing convergence guard must remain green.
2. The blanket Method/type-like-parent exemption preserves the main false-positive class: an unrelated axios.get can still resolve through unique_name when the sole candidate is labeled Method. The new negative test uses a Function, so it does not exercise that common path.
3. Add direct coverage for the unique and multi-candidate paths, imported receivers, . and :: qualification, and candidates labeled Method.
4. Use the canonical cbm_label_is_type_like() policy rather than duplicating the label set in the registry.

The precision goal is valid, but the registry currently lacks enough receiver/language/type evidence for this global heuristic: it is simultaneously too strict for valid Java dispatch and too permissive for unrelated Method candidates. Please redesign the suppression around receiver-aware evidence, preserve the Java enum convergence test, and update the PR's “full suite clean” statement after the complete matrix is actually green.

@DeusData the registry fix it ready to be reviewed!

Thanks for the update. I see current head e6e537759e176e8a23d06828ea2808b7cff16fc8 and a green matrix. The exact-head re-review will focus on the prior Java enum-dispatch regression and Method-labelled receiver false positives before we give further technical feedback. No additional contributor action is requested in the meantime.

Thank you for this — the false-positive class you are killing is real, and your tests demonstrate it convincingly. axios.get resolving to an unrelated same-named method on main today is exactly the kind of wrong edge that erodes trust in the graph. I want to be specific about what I verified, because two things need your attention before a merge decision.

What holds up. The registry logic is sound and the new tests bind. Restricting suffix matching on receivers is a defensible precision improvement, and the thread-local _import_map_cache use is fine.

1. A regression the tests cannot see — Java enum constants.

The diff rewrites find_class_body to descend enum_body → enum_body_declarations. But extract_enum_members walks the direct children of whatever find_class_body() returns, looking for enum_constant nodes. In tree-sitter-java, enum constants are children of enum_body — they are siblings of enum_body_declarations, not inside it.

The consequence: for any Java enum that also declares methods, the constants (MON, TUE, …) stop being extracted as Variable nodes. They just disappear. Your java_enum_method test asserts only the Enum and its Methods, so CI stays green while the constants are lost.

Worth adding a test that asserts the constants and the methods on the same enum — that would have caught this and will stop it recurring.

2. Scope — there is a second feature in here.

The description covers the registry precision change. The diff also rewrites find_class_body, adds a Java identifier-fallback for class names, and extends push_class_body_children for enum_body/enum_body_declarations. That is Java enum extraction work, and I suspect it was added to make the receiver-awareness test's Java case pass.

We hold to atomic PRs, so I would like to see this split: the Java-enum extraction improvement is independently valuable and should land on its own merits (with the constants bug fixed), and the registry change should stand or fall on its own.

3. One question that is above my pay grade, so I have referred it to the maintainer.

This changes the precision/recall balance of the resolution core for every language at once, and I could not find evidence of what it costs. The self-receiver list is hardcoded {self, this, cls, @self} — that misses $this in PHP and Me in VB, and C++ ns::helper() calls will stop resolving where namespaces are not part of the qualified name. Killing false positives is good; losing true CALLS edges is a findability regression, and we care about that more.

We have a per-language benchmark and evaluation harness precisely for this kind of trade-off. The maintainer will decide whether this needs to go through it first. That is not a criticism of your work — it is a question about how much evidence a change to the resolution core needs, and it is his call rather than mine.

Points 1 and 2 are worth acting on regardless of how point 3 lands. Thanks again for digging into a genuinely hard part of the system.

Follow-up with more detail, now that I have also reviewed your #893 and closed it in favour of this PR (nothing unique was lost — the comparison is in that thread).

Reviewing the two together produced a sharper picture of the recall risk I flagged earlier. This is not a request to change anything yet, since the direction call is the maintainer's — but the specifics are worth having on the record, because they are the evidence that decision will rest on.

Where the receiver heuristic loses true edges. The self-receiver list is {self, this, cls, @self}, matched against raw callee node text. Concretely:

• PHP emits $this.helper with the sigil preserved, so "$this" is not in the list.
• Perl convention is $self.
• VB.NET is Me.
• Rust associated calls are Self::new.

PHP and Rust have LSP cover, but the registry is their fallback path; VB-style languages have neither. This matters more than it might look, because cbm_registry_resolve splits at the first separator, so for roughly 150 non-LSP languages this heuristic is the primary resolver.

Two further recall paths I had not previously named:

1. Multi-segment module-qualified callees. The prefix check uses only the first segment, so pkg.service.get inside module proj.pkg.service fails Strategy 2 ("pkg" ≠ module tail "service"), while the less qualified service.get passes — the more precise reference resolves worse than the vaguer one. Strategy 3 can rescue it via the qualified tail, but only below REG_MAX_CANDIDATES; at our scale the hot names (get, add, update) blow straight past that cap and come back empty. Strategy 2's module fallback was the scale-proof path for exactly those names.
2. Alias receivers. The resolve_name_lookup enforcement drops true edges for Function candidates behind an alias: Elixir alias Foo.Bar, as: B; B.helper() yields a winner proj.foo.bar.helper that does not end in B.helper, so it resolves to nothing where it previously resolved correctly. The same shape hits Ruby constant aliases and CommonJS const u = require('./utils'); u.helper() whenever import extraction misses the alias. Elixir aliasing in particular is idiomatic essentially everywhere.

Your PR description is candid that the change "heavily favours precision", and that honesty is appreciated — it is also precisely why this needs a maintainer decision rather than a reviewer's. This project's stated priority runs the other way: a false edge is noise, but a lost true edge is a thing an agent can no longer find. Killing axios.get false positives is a real win, and I do not want to lose it; the question is what it costs across the other languages, and that is measurable with the per-language bench and eval harness rather than arguable.

Also worth noting independently of all of the above: there is no test anywhere in the suite that asserts Java enum constants. That is why the enum defect I raised earlier stays green in CI on this PR, on #893, and on #984. Worth adding regardless of which way the direction question lands.

Nothing for you to do on the direction question — that is ours to answer, and I will come back to you. The enum constants fix and the Java gating from my earlier comment are still the concrete asks.

An update that makes this easier to settle, and it replaces prose with a test.

The regression I described is now pinned on main. tests/test_extraction.c:482-483, inside java_enum_dedup_preserves_calls_issue1234, now asserts:

ASSERT(has_def(r, "Variable", "MON"));
ASSERT(has_def(r, "Variable", "SUN"));

That is the guard for enum constants surviving alongside enum methods, and it is exactly what the find_class_body change bundled into this branch breaks. So rather than taking my word for it, rebase onto current main and run build/c/test-runner extraction — you will see it go red, and you will see precisely which behaviour changed. That is better evidence than my description, and if it turns out I have misread your change, the test will show that too.

To be clear about why this matters beyond one test: dropping enum constants is a graph-quality regression that no consumer can see. The nodes simply are not there, so nothing errors — searches just quietly return less. That is the failure mode this project treats as the worst kind.

The bigger question is still open and it is the one blocking merge. Restricting same-module and unique-name suffix matching genuinely improves precision — I am not disputing the premise, and over-eager suffix matching does mint wrong edges. But my read is that it also costs recall in PHP, Perl, VB.NET and Rust, where the resolver leans on suffix matching more heavily than it does in the languages you tested against.

I do not want to decide that from either of our intuitions. What would settle it is measured per-language edge-count deltas: index the same corpus before and after your change and report CALLS-edge counts per language. If precision rises without meaningful recall loss outside the cases you targeted, that is a merge. If PHP or Rust drops a large fraction of its call edges, we need a narrower rule.

If gathering that is more than you want to take on, say so — it is a fair amount of work, and I would rather know than have this sit for another month. I can run the measurement myself if you would prefer to hand it over.

One process note for whenever you next push here: the find_class_body change is not mentioned in the PR description, which claims only the registry suffix-match restriction. A reviewer looking for what you described would not go looking in the class-body walker. Whatever we conclude on the main question, please split that out or describe it — a bundled change is the one thing that reliably makes a review miss something.

Open since 16 July with no reply from us at all. Seven weeks of silence on 378 lines of careful work is not acceptable, and I am sorry. Here is a real review.

The finding that decides it

Test Case D and Test Case E are right — a qualified receiver (Service.get, Service::get) should resolve. But Test Case C asserts the exact false positive this PR sets out to remove:

/* Test Case C: Receiver that is an unregistered/instance variable (e.g. "d.get") */
{
    cbm_resolution_t res = cbm_registry_resolve(r, "d.get", "proj.app", NULL, NULL, 0);
    ASSERT_STR_EQ(res.qualified_name, "proj.pkg.Service.get");
}

d is an unregistered receiver and the import map is empty (NULL, NULL, 0). Nothing connects d to proj.pkg.Service — yet the test requires the resolver to bind them. That is the axios.get → project.get shape, written down as desired behaviour.

So the suite documents the change failing its own stated goal. Whatever else is right here, a reviewer cannot accept a precision fix whose tests demand the imprecision, and I would rather tell you that plainly than let it sit for another seven weeks.

The architectural constraint you could not have known

This is the part that is genuinely on us for not saying in July.

Receiver-precision fixes in this project are written as per-language suppressors, gated on the file's language, and wired at both pass_calls.c and pass_parallel.c — not as changes to the strategies inside cbm_registry_resolve. All three existing guards follow that shape, and every one deliberately preserves the same_module path.

The reason is concrete. Go receiver methods carry a flat qualified name (pkg.Area, not pkg.Circle.Area), so c.Area() resolves only through the same_module suffix branch that a global restriction gates off. And roughly 150 languages without an LSP use this chain as their only resolver, so the blast radius is far wider than the languages anyone tests. A blocked high-confidence match does not vanish either — it is demoted from same_module (0.90) into suffix_match (0.55), which picks a winner by import distance project-wide. A global restriction can therefore lose a correct edge and mint a wrong one in the same step.

Your PR is the most global member of this family: it changes strategies inside cbm_registry_resolve itself, where the others add suppressors downstream.

A global change is not categorically refused, but it has to carry an unusually strong case: that the upstream strategies are provably untouched, a measured per-language blast radius on real codebases with the refusals hand-read, no per-language seam available at that point, and a demonstration that confidence scoring cannot do the job instead. That bar has been met once, by a PR that measured three real codebases and hand-read every refusal.

Where that leaves this

I am not closing it — that is the maintainer's call and I have not asked. But as it stands it cannot merge, for the test reason above independently of the architectural one.

If you want to take it further, the shape most likely to land is: drop Test Case C or invert it to assert the non-resolution, move the restriction into a per-language suppressor gated on the file language and wired at both call sites, and bring a measurement of what it removes and keeps on a real repository.

It is also long since conflicted with main. Please do not spend time rebasing until you have decided whether you want to pursue the reshaped version — I would rather not cost you more work on top of the wait.

Thank you for the report and the work, and again, sorry for the silence.

Hi @DeusData,

Thank you for the detailed feedback. I have rebased the PR cleanly onto main and addressed your review notes:

1. Uncoupled from Java Enum Extraction: The bundled find_class_body changes were dropped since they were already resolved upstream in 5eae0a43. This PR now focuses purely on receiver precision.
2. Inverted Test Case C: Inverted d.get with an empty import map to assert non-resolution (NULL), matching the intended precision goal and eliminating the false positive.
3. Preserved Go & Qualified Suffix Dispatch: Maintained Go flat receiver dispatch (c.Area()) and allowed qualified attribute chains in the same module while strictly preventing unrelated bare receivers (like axios.get or _get_store().get) from resolving to local functions.
4. Builtins Compatibility: Builtin types like builtins.dict.get remain resolvable as unique-name matches, while foreign project methods and functions require matching receiver qualifications.

All 94 tests in SUITE(registry) are passing cleanly.

Hi @DeusData,

Refined the implementation in line with your review notes and precision guidance:

1. Dropped Test Case C: Completely removed the unregistered instance variable test case (d.get) to avoid imposing an artificial global restriction that penalizes untyped instance dispatch across non-typed languages.
2. Context-Aware Receiver Restriction in Name Lookup:
   • For Function candidates (free functions): qualification is strictly required (qn_ends_with_qualified), preventing arbitrary receiver bindings (e.g. unrelated.compute does not bind helper.compute).
   • For Method candidates: receiver mismatches are rejected only when the receiver prefix is an imported alias (is_imported_receiver) or a known Type/Class/Module/Namespace in the registry (is_known_type_or_namespace), preventing cross-namespace collisions (axios.get and other_service.get do not resolve to Service.get).
   • Untyped local instance receivers (e.g. vm.load, c.val(), client.get()) are preserved without regressions.
3. Same-Module Precision: Preserved Go flat receiver dispatch (c.Area()) and self/module qualifications, while preventing unrelated receivers (axios.get, _get_store().get) from resolving to local module functions.

All changes are formatted with clang-format -i and signed off with DCO.

@sahil-mangla, a quick follow-up to our review from yesterday, before you put time into it: we ran the suppressor shape we asked for (items 2 and 3) on two real JavaScript/TypeScript repositories, and it removes too many correct edges. In JS/TS, methods of an object literal (const context = { push() {...} }, as in Vue's createCodegenContext) and functions assigned onto an object (Translator.create = function create() {...}) are stored as plain module-level functions, so context.push() reaching the module's push through the same-module lookup is usually right. On vuejs/core about half of the removed edges were correct ones like that; on NodeBB about one in four. That is the same trap as Go's flat receiver methods, one level over, and the miss was in our ask, not in your code.

So please hold off on items 2, 3 and 6 for now: we are working out a narrower shape and will come back to you with it. Item 1 of the review (leave the strategy chain in registry.c unchanged) still stands; with that alone the three failing pipeline tests pass.

Thank you for your patience with this one, and for finding the class in the first place.

Thanks for your patience and the receiver-resolution work. Our later October 19 correction still applies: please hold items 2, 3 and 6 while we settle the narrower approach; the request to leave the registry strategy chain unchanged stands. Sorry for the delay on our follow-up—I’ll come back to you soon.

@sahil-mangla, a short update so this does not look forgotten: we have settled the narrower shape. The same-module lookup will be refused only for a member call whose receiver is bound to an import (an ES import, a CommonJS require, or an AMD dependency) or is a builtin global such as console or Math - exactly your axios.get case - while calls like context.push() on an object-literal method keep their edges. Since you allowed maintainer edits, we will make that change on your branch ourselves: it replaces the registry.c strategy changes (item 1 of the review) and keeps your test cases as the positive and negative controls, and we will add a before/after edge count on real JavaScript/TypeScript repositories and explain every commit here. Nothing is needed from you in the meantime. Thank you for finding this class of wrong edge and for your patience while we got the shape right.

@sahil-mangla, thank you for sticking with this one. You found a real class of wrong edge - axios.get() binding to whatever get the calling file happens to define - and your test cases pin it down precisely. As announced earlier today, we have now pushed the narrower shape onto your branch (thank you for allowing maintainer edits). Here is what each commit does and why.

1. feat(extract): record JS/TS receiver binding facts for imports and AMD (34c64bf)
   The guard has to know, from the calling file's own source, whether a receiver is bound to another module. Two facts were missing. First, an import statement that binds no name (a side-effect import './x', a re-export, require('x').y) still records the last segment of its path as its local name, so require('node:stream') made every parameter called stream look like an import. Those entries are now marked as synthesized; the import map and the IMPORTS edges are unchanged. Second, AMD: define(['api'], function (api) { ... }) binds api to a dependency with no import statement at all. The extractor now carries that binding through its walk, scoped to the factory function, the same way it already tracks Python parameters, and records it on the call. The CommonJS-wrapper dependencies exports, module and require stay unbound, because they are the module itself. This commit on its own does not change the graph.

2. fix(pipeline): refuse same_module for import-bound or builtin JS/TS receivers (51c57c4)
   This restores the strategy chain in registry.c to main (item 1 of the 19 October review) and adds a call-site suppressor instead, applied identically in pass_calls.c and pass_parallel.c, with the language list inside the helper: JavaScript, TypeScript, TSX, ArkTS, and the script bodies of Vue, Svelte, Astro and HTML files. A member call keeps its same_module edge unless the lookup had to drop the receiver to find the target AND that receiver is an ES import or a CommonJS require of the file, an AMD dependency, or a builtin global (console, Math, JSON, Object, Reflect, process, and a few more). Every other receiver keeps its edge, including context.push() on an object-literal method, this.get() and exports.get(). A call such as search.init() that matched <module>.search.init as a whole also keeps its edge, because there the receiver is part of the match. Your two registry tests are kept as the positive and negative controls, now at the level of the guard. One case changed sides: _get_store().get is now a positive control, because a call result carries no binding fact, so under the agreed shape it keeps its edge. New pipeline tests (sequential and parallel) cover all eight languages plus CommonJS and AMD, and two extraction tests cover the new facts.

3. Merge of current main (9f5923c). The only conflicts were the suppression expressions in the two resolver files, where main had added two clauses next to ours; all of them are kept.

Before and after on two real repositories (fresh full index on current main; sequential and parallel indexing give identical graphs, and repeated runs are identical):

We read every one of the 49 removed call sites (6 in vuejs/core, 43 in NodeBB) against the source, and each one was a wrong edge. Some examples: Object.defineProperty(...) bound to a proxy handler's own defineProperty, Reflect.get(...) bound to a collection handler's get, nconf.get(...) bound to a controller's get, winston.info(...) bound to a CLI command named info, and the AMD dependency categorySelector.init(...) bound to the calling module's own init. No new caller/target pair appears. The edge count drops by slightly less than the number of call sites, because three of the pairs are still reached through another, correct call in the same function.

The new pipeline tests fail on main for every language and pass with these commits. The registry, pipeline, extraction, TypeScript LSP and complexity suites pass under ASan/UBSan.

Since we pushed to your branch, please pull before pushing again. Thank you again for your patience with this one, and for finding the class in the first place.

Merged - thank you very much, @sahil-mangla, for finding this class of wrong edge and for your patience while we worked out the right shape.

A member call whose receiver is an ES import, a CommonJS require, an AMD dependency or a builtin global such as console or Math no longer gets a same_module edge to whatever same-named function the calling file happens to define, while calls on local objects keep their edges. On vuejs/core and NodeBB every one of the 49 edges this removes was a wrong one, such as Object.defineProperty(...) landing on a proxy handler's own defineProperty, and no new edge appeared. Your test cases now guard the rule as its positive and negative controls. Thanks again!