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.