Repository navigation
Scala: receiver.method(...) calls are bound to an arbitrary same-named symbol by short name (weak-member suppression not applied) #2155
Description
Version
Built from source, main @ 9b24332 (v0.10.8-181)
Platform / Install channel / Binary variant
Linux (x64) / Built from source / standard
What happened, and what did you expect?
Scala has no LSP resolver, so a member call such as map.get(key), _.register(x) or builder.build() falls through to the registry and is bound to an arbitrary project-wide get / register / build by short name. On a project with a few hundred Scala files this produces many confident-looking but wrong CALLS edges (e.g. every .get on an Option/Map pointing at some unrelated def get).
Python and the JS/TS family already have a receiver-aware guard for exactly this case (weak short-name matches on receiver.method(...) are suppressed unless an import-map or same-module match exists). Scala calls are not marked as member calls, so the guard never applies.
Expected: Scala receiver.method(...) calls are flagged as member calls and go through the same weak-member suppression; import-map and same-module matches stay eligible.
Same class of problem as #1906 (Go selector calls) and #2053 (Rust std-typed receivers), for Scala.
Reproduction
- Dummy snippet:
package a
class Registry { def register(x: Int): Unit = () }package b
object Job {
def run(items: Map[String, Int]): Unit = {
items.get("k") // scala.collection — no target in the project
items.foreach(_.register) // not a.Registry
}
}-
Command:
codebase-memory-mcp cli trace_path '{"project":"repro","function_name":"register","direction":"inbound"}' -
Result:
b.Job.run → a.Registry.register(strategyshort_name, low confidence).
Expected: no edge.
A second symptom fixed alongside: try_field_type_hint picks between identically named owners in different packages by iteration order; when the hint is ambiguous it should leave the low-confidence registry result so the guard can suppress it deterministically (sequential and parallel indexing currently may disagree).
Proposed fix
Mark Scala receiver.method(...) as is_method, enable the existing receiver-aware weak-member suppression for Scala, and make the ambiguous field-type hint fail closed. One commit with pipeline tests (sequential + parallel). Stacked on #2153 / #2154 (shared fixtures); branch:
https://github.com/htarnacki/codebase-memory-mcp/tree/feat/scala-receiver-resolution (third commit).
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet), not proprietary code.
Activity
DeusData commentedon Sep 25, 2026
Thank you @htarnacki. This was a clear, well-scoped report, and your repro snippet showed the exact shape. You were right that the Python/JS receiver guard never applied to Scala, because Scala calls were never flagged as member calls in the first place.
Since you already have a fix on your branch, we'd love for you to carry this one. To help, here's what we found while measuring the same approach locally, in case it's useful for your PR:
recv.m(...)(including curriedrecv.m(a)(b)) and named infixrecv m argas member calls when the receiver is a value, and add Scala to the weak-member suppression in both resolvers (pass_calls.candpass_parallel.c, kept identical). Leavethis/super, upper-case object/type paths (Utils.helper,Bijections.finagle.m) and upper-case applies through a package path (http.param.Streaming(x)) unflagged; the registry's receiver-chain check already covers those.unique_name/field_type_hintmatches whose target is in the caller's own file restored true edges (and keeps the existingmkc_c7_scala_inherited_methodpin green);suffix_matchstays suppressed.math.max→ a projectmax,items.get→ToggleMap.get,str.getBytes→Row.getBytes), ~25% were real calls (client.zRem,stack.contains→Stack.contains) that only a type-aware resolver could keep. A possible refinement is to keep Scalaunique_nameedges unless the name is a Scala/Java stdlib member (modelled on the Python builtin-member list); in our sample that kept ~10 true / 5 false per 25.Your point about the ambiguous field-type hint is noted as a separate follow-up, because that heuristic is shared by every language (and it currently only exists in the parallel resolver). Once your PR is up we'll review it promptly. Thanks again for the careful write-up!
fix(scala): suppress weak short-name matches for receiver calls
fix(scala): suppress weak short-name matches for receiver calls
fix(scala): suppress weak short-name matches for receiver calls
fix(scala): suppress weak short-name matches for receiver calls
DeusData commentedon Oct 19, 2026
Thank you again for the Scala receiver cases. I have no new verified status beyond the September 25 guidance. The weak-member suppression and shared ambiguous field-hint behavior remain distinct review concerns.
DeusData commentedon Oct 25, 2026
Thank you again for the receiver examples and proposed suppression work. The weak-member policy and shared ambiguous field-hint behavior still need maintainer follow-up. Sorry for the delay; I’ll follow up soon.