hir_def

Module item_tree

source
Expand description

A simplified AST that only contains items.

This is the primary IR used throughout hir_def. It is the input to the name resolution algorithm, as well as to the queries defined in adt.rs, data.rs, and most things in attr.rs.

ItemTrees are built per HirFileId, from the syntax tree of the parsed file. This means that they are crate-independent: they don’t know which #[cfg]s are active or which module they belong to, since those concepts don’t exist at this level (a single ItemTree might be part of multiple crates, or might be included into the same crate twice via #[path]).

One important purpose of this layer is to provide an “invalidation barrier” for incremental computations: when typing inside an item body, the ItemTree of the modified file is typically unaffected, so we don’t have to recompute name resolution results or item data (see data.rs).

The ItemTree for the currently open file can be displayed by using the VS Code command “rust-analyzer: Debug ItemTree”.

Compared to rustc’s architecture, ItemTree has properties from both rustc’s AST and HIR: many syntax-level Rust features are already desugared to simpler forms in the ItemTree, but name resolution has not yet been performed. ItemTrees are per-file, while rustc’s AST and HIR are per-crate, because we are interested in incrementally computing it.

The representation of items in the ItemTree should generally mirror the surface syntax: it is usually a bad idea to desugar a syntax-level construct to something that is structurally different here. Name resolution needs to be able to process attributes and expand macros (including attribute macros), and having a 1-to-1 mapping between syntax and the ItemTree avoids introducing subtle bugs.

In general, any item in the ItemTree stores its AstId, which allows mapping it back to its surface syntax.

Structs§

Enums§

Traits§

Type Aliases§