Skip to main content

Crate nova_resolver

Crate nova_resolver 

Source
Expand description

Name resolution for the Nova compiler.

Phase 1 scope: a single-file module. The resolver walks the top-level items of a parsed nova_ast::File and produces a Definitions table mapping every top-level name (functions, sum types, sum-type variants, constants) to a stable DefId. Duplicate definitions are reported as E0002 diagnostics.

Local (block-scoped) variable resolution happens during type checking, where scoping interacts with inference; this crate owns the item-level namespace and the shared DefId / Res vocabulary used by the rest of the pipeline.

Re-exports§

pub use index::Index;
pub use index::LocalFlags;
pub use index::Occurrence;
pub use index::Role;
pub use index::Target;

Modules§

index
The index of name occurrences the language server reads (spec docs/superpowers/specs/2026-10-10-phase-3-4a-navigation-design.md §3).

Structs§

Def
A single top-level definition.
DefId
A stable identifier for a top-level definition within a module.
Definitions
The item-level namespaces of a whole program (one or more modules).
Exported
What a module exports under one name, in each namespace (spec 3.4b §4.2).
ModuleId
Index of a module within a compiled program.
ModuleSource
A source module: a parsed file, its label, and what its imports name.
ProgramResolution
Output of resolve_program: the merged file, its namespaces, any diagnostics, and the @test functions collected along the way. The merged file’s item_indexes are what Definitions refers to, so downstream stages consume both together.
ResolveResult
Output of resolve: the namespace table, the merged file whose item_indexes the definitions refer to (the input plus the implicit std modules, see STD_MODULES), and any diagnostics. Downstream stages must type-check against this file, not the original input, since item_indexes index into it.
TestFn
A well-formed @test function, collected by [collect_item] in the same order resolve_program’s item walk visits it — source order (modules in registration order, items within a module in file order; see collected_tests_are_in_source_order_with_should_panic_attached in nova-typeck for why that order must be exact and stable). Task 3 reads this to build a dispatching main that runs one test per process, selected by index; Task 5 reads test names back out of the compiled binary, not from this struct directly — so an index and a name can never silently disagree between the two only if this order never does either.
VariantDef
One variant of a sum type.

Enums§

Builtin
A compiler-provided builtin function.
DefKind
What kind of definition a DefId refers to.
ImportTarget
What an import names, by its first segment (spec 3.3a §4.5).
MethodOwner
Where a DefKind::Method lives.
Res
What a name in expression position resolves to.
ScopeEntry
What a name in a module’s scope is bound to: what completion offers (spec docs/superpowers/specs/2026-10-08-phase-3-2-lsp-core-design.md §4.3).

Constants§

RESERVED_TYPE_NAMES
Type names the compiler owns, which a user type declaration may not take.
STD_MODULES
The embedded standard-library modules, compiled as implicit modules and glob-imported into every user module. Order is significant only in that it fixes module indices; user modules always come first, then these in the order listed here — std/core stays first so its module index is unchanged from when it was the only embedded module. The sources come from the nova-std crate, which embeds std/ at build time through paths inside its own package, so the compiler stays a single self-contained executable and cargo package keeps the files. Each name is $std.*, not a valid identifier, so it can never collide with a user module name or be named in an import.
STD_TEST_MODULE
std/test, seeded only under nova test. Kept out of STD_MODULES so that array’s length does not depend on compilation mode: every consumer iterates it and the driver allocates one FileId per entry, so a conditional member would make FileId allocation depend on which subcommand is running.

Functions§

name_imports
Fill each module’s import table by module name, as a program without packages has always resolved (ADR 0003): import m names the first module called m. Every other module becomes importable by its name (spec 3.4b §4.6).
resolve
Collect the item-level namespace of a single file.
resolve_program
Resolve a multi-module program: collect each module’s item namespace, enforce pub visibility across modules, wire up imports, and merge all items into one file for whole-program compilation downstream.