Struct HoverAnalysis 

pub struct HoverAnalysis<'a> {
    pub index: &'a ProjectIndex,
    pub snapshots: &'a HashMap<PathBuf, String>,
    pub locals: &'a FileLocals,
    pub expr_types: &'a FileExprTypes,
    pub tys: &'a Types,
    pub rel: &'a Path,
    pub offset: usize,
    pub project_root: &'a Path,
    pub doc_scope: &'a HashMap<String, Vec<String>>,
    pub boundary_info: &'a HashMap<String, ContextBoundaryInfo>,
    pub context_count: usize,
}

The analysed round’s tables, positioned at the cursor.

Fields

index: &'a ProjectIndex

snapshots: &'a HashMap<PathBuf, String>

Project-relative path → the analysed text.

locals: &'a FileLocals

expr_types: &'a FileExprTypes

tys: &'a Types

T3.6b (R4.1): the table expr_types’ TyIds resolve against.

rel: &'a Path

The cursor’s file (project-relative) and its offset into the snapshot.

offset: usize

project_root: &'a Path

#848: the round’s project root — resolves a doc-link’s SiteRef into a file:// hover-Markdown target.

doc_scope: &'a HashMap<String, Vec<String>>

#848: qualified unit name → its doc-comment intra-doc-link search order, for rung 1’s doc-link rewrite.

boundary_info: &'a HashMap<String, ContextBoundaryInfo>

#855: qualified context/adapter unit name → the combined type table and service/agent tables the wire-contract peek needs.

context_count: usize

#855: how many real contexts/adapters this project has — computed once per round by the transport with bynk_ide::wire_contract::real_context_count, never re-derived here as a bare boundary_info.len() (see that function’s doc: the synthetic toolchain bynk capability unit would otherwise count as a second “context” and NoCrossContextReason::SingleContext would almost never fire).