Rust: a receiver with more than one field access is dropped from the call reference (self.a.b.m() recorded as m) #2836

A Rust method call whose receiver has more than one field access is recorded with the bare method name: self.services.store.put(…) becomes put. The receiver is lost before resolution, so the call stays unresolved or is matched by name only, and refName on a resolved edge carries no receiver either. One field access keeps it.

Repro

1.6.2, a Cargo workspace with api (trait Store { fn put(&self, key: &str); }) and app depending on it:

use api::Store;

pub struct Services { pub store: Box<dyn Store> }
pub struct Svc { pub services: Services, pub store: Box<dyn Store> }

impl Svc {
    pub fn a(&self) { self.services.store.put("a"); }
    pub fn b(&self) { let _ = self.services.store.put("b"); }
    pub fn c(&self) {
        self
            .services
            .store
            .put("c");
    }
    pub fn d(&self) { self.store.put("d"); }
    pub fn e(&self) {
        self
            .store
            .put("e");
    }
}

unresolved_refs after codegraph init:

A call inside the chain drops it the same way: self.store().put("m") is recorded as put.

Why it matters

This is the shape of most service-layer calls (self.services.storage.update(…)), and rustfmt splits it over several lines, which made it look like a line-break problem at first. Without the receiver:

• receiver-type inference has nothing to start from, so the call is unresolved or name-matched;
• name-matched edges get the same low confidence (0.4, exact-match) as iterator calls such as v.into_iter().next() landing on a project method named next, so confidence cannot separate a real call from a false one;
• tools reading metadata.refName cannot tell which field the call goes through.

Expected

reference_name / refName keep the full receiver path, e.g. self.services.store.put, as they do for self.store.put. For a call in the chain, at least the path up to the call (self.store()).

Related: #2614 (std/external receivers linking to same-named project methods), #750 (chained factory/singleton resolution).