Struct GraphIndex 

pub struct GraphIndex<'g> {

    pub graph: &'g Graph,
    pub root: PathBuf,
    pub by_id: HashMap<String, usize>,
    pub by_file: HashMap<String, Vec<usize>>,
    pub by_simple_name: HashMap<String, Vec<usize>>,
    pub by_lower_name: HashMap<String, Vec<usize>>,
    pub inbound: HashMap<String, InboundEntry>,
    pub outbound_by_file: HashMap<String, OutboundEntry>,
    pub ambiguous_by_candidate: HashMap<String, Vec<usize>>,
    pub ambiguous_by_file: HashMap<String, Vec<usize>>,
    pub heuristic_inbound: HashMap<String, HeuristicEntry>,
    pub heuristic_outbound_by_file: HashMap<String, HeuristicEntry>,
    pub test_defs_by_file: HashMap<String, Vec<usize>>,
    pub flagged_files: HashSet<String>,
    pub manifest_present: bool,
    pub ctor_di_by_to: HashMap<String, Vec<usize>>,
    pub ctor_di_fanin: HashMap<String, usize>,
    pub hub_indegree: HashMap<String, usize>,
}

The built query index over a Graph. by_id/by_file/by_simple_name/ by_lower_name store graph.defs indices rather than cloned Defs, so a def is never copied into every bucket it is reachable from.

Fields

graph: &'g Graph

The graph value.

root: PathBuf

The repository root every file in the graph is relative to. Held so a query can read the one source line a hit sits on; nothing else in this module touches the filesystem.

by_id: HashMap<String, usize>

Def id -> index into graph.defs.

by_file: HashMap<String, Vec<usize>>

File -> the def indices declared in it. The Vec preserves insertion order (defs-array order for a def’s own file, then also_in cross-references in defs-array order) – impact_walk’s next-frontier expansion iterates this in order, one of the order-sensitive paths documented in the module header.

by_simple_name: HashMap<String, Vec<usize>>

Exact name -> def indices, insertion order = graph.defs array order.

by_lower_name: HashMap<String, Vec<usize>>

Lowercased name -> def indices.

inbound: HashMap<String, InboundEntry>

Def id -> its inbound edges by kind (inherits/uses-type/uses-member).

outbound_by_file: HashMap<String, OutboundEntry>

File -> its outbound edges by kind (inherits/uses-type/uses-member/imports).

ambiguous_by_candidate: HashMap<String, Vec<usize>>

Candidate def id -> the ambiguous edges naming it as a candidate.

ambiguous_by_file: HashMap<String, Vec<usize>>

Source file -> the ambiguous edges originating in it.

heuristic_inbound: HashMap<String, HeuristicEntry>

Def id -> its inbound HEURISTIC edges by kind. Heuristic edges live in their own adjacency, never mixed into the precise one, so every consumer (the impact walk’s frontier, the refs tables, PageRank’s edge set) reads only precise edges unless it asks for guesses by name. Mixing them in and filtering later is the shape that eventually leaks a guess into a fact – a filter forgotten in one call site is silent.

heuristic_outbound_by_file: HashMap<String, HeuristicEntry>

File -> its outbound HEURISTIC edges (same three-kind shape).

test_defs_by_file: HashMap<String, Vec<usize>>

File -> the defs declared in it that carry non-empty test_methods. A file is a TEST file here because a type declared in it carries an attribute a runner discovers, never because of what it is called. Every declaring site counts (def.file plus each also_in), and the per-def file dedup keeps two partial blocks in ONE file from listing that def twice. Holds graph.defs indices, same convention as the buckets above.

flagged_files: HashSet<String>

Files present in the graph but absent from the manifest.

manifest_present: bool

Whether a manifest was found and parsed.

ctor_di_by_to: HashMap<String, Vec<usize>>

Implementor def id -> every ctor-di edge the resolver confirmed resolves TO it. Only an edge carrying a to is indexed here – ambiguous/infra/unresolved edges never do, so an infra leaf like ILogger<T> can never enter this map by construction.

ctor_di_fanin: HashMap<String, usize>

Injected-type BARE NAME -> the number of DISTINCT CONSTRUCTOR SITES (from_file + from_line) that inject it. A ctor-param ref carries its constructor’s line, so every parameter of one constructor shares one site; two classes in one file still count twice. This is the graph’s proxy for “distinct consuming classes”. Every ctor-di edge counts, whatever its resolution: how widely a contract is injected is a fact about the contract, not about whether an implementor was confirmed.

hub_indegree: HashMap<String, usize>

File -> the number of DISTINCT OTHER FILES that reference it through a direct (inherits/uses-type/uses-member) or heuristic edge. The file-level mirror of ctor_di_fanin, over the two edge kinds responsible for the reach a fan-in brake cannot see. Distinct REFERRING FILES, not distinct edges: one neighbour naming a hub fifty times is still one neighbour. A file’s references to ITSELF are excluded – a file is never its own dependant.

Implementations

impl<'g> GraphIndex<'g>

pub fn def(&self, id: &str) -> Option<&Def>

Look up a def by id, e.g. for rendering an ambiguous candidate’s {file, line, kind}. Spelled as a method so callers don’t reach through by_id plus index arithmetic themselves.