Struct DefIndex 

pub struct DefIndex {
    pub defs: Vec<Def>,
    pub member_lists: Vec<MemberLists>,
    pub qualified_name_to_def: HashMap<String, usize>,
    pub qualified_name_and_arity_to_def: HashMap<(String, usize), usize>,
    pub simple_name_to_defs: HashMap<String, Vec<usize>>,
    pub extension_index: HashMap<String, Vec<ExtCandidate>>,
    pub member_name_to_defs: HashMap<String, Vec<usize>>,
}

Vec<Def> in first-insertion order (partial-class duplicates land in also_in, never as a second Vec entry) plus two lookup indexes over it: qualified_name_to_def (id -> index, every def incl. enum members) and simple_name_to_defs (bare name -> indexes, EVERY def EXCEPT enum members – the asymmetry described in the module header).

Fields

defs: Vec<Def>

The defs value.

member_lists: Vec<MemberLists>

Parallel to defs (same indexes), NOT fields on Def: a def’s property/field lists are RESOLUTION inputs only. No graph.json reader consumes them (graph-query walks EDGES), so serializing them would multiply the def table’s size on disk and in every scout refs/scout impact read for nothing. Keeping them off Def keeps the on-disk def rows to exactly the serialized fields.

qualified_name_to_def: HashMap<String, usize>

The qualified name to def value.

qualified_name_and_arity_to_def: HashMap<(String, usize), usize>

The qualified name and arity to def value.

simple_name_to_defs: HashMap<String, Vec<usize>>

The simple name to defs value.

extension_index: HashMap<String, Vec<ExtCandidate>>

The extension tier’s own lookup: “<method_name> <this_type>” (one ASCII space) -> every candidate declaring that PAIR, as (def index, entry).

The key was the (name, this_type, arity) TRIPLE until the range amendment. Arity moved out of the key and into a per-entry range filter because an exact arity is not the language’s rule: Send(this T t, X a, Y b = null) accepts two OR three arguments, and keying on 3 alone made a call with two arguments miss it – which in turn made a DIFFERENT class’s exact-arity-2 Send look like the only candidate and win an edge it had no right to – the false-uniqueness shape.

Build order is def order – files in fragment-map order, defs in source order, extension entries in declaration order – so a bucket holding two candidates holds them in the same order on every run. The tier refuses on a 2-candidate bucket anyway; the order is pinned because it is what a later scored tier would read.

member_name_to_defs: HashMap<String, Vec<usize>>

Member name -> every def that vouches for a member of that name, the pool the scored tier’s UNIQUENESS FALLBACK draws from when a ref’s qualifier resolves to nothing at all (x.Tally() where the extractor could vouch for no type for x). Built AFTER the main def loop, not during it, so a partial class contributes its accumulated member set once instead of appearing in a bucket per declaring file.

Insertion order is def order (fragment order, then source order), and within one def the names are collected methods -> properties -> fields -> extension-method names, first insertion winning. This order decides which candidates a <= SCORED_UNIQUENESS_CAP pool holds.