Expand description
HIR (previously known as descriptors) provides a high-level object-oriented access to Rust code.
The principal difference between HIR and syntax trees is that HIR is bound to a particular crate instance. That is, it has cfg flags and features applied. So, the relation between syntax and HIR is many-to-one.
HIR is the public API of the all of the compiler logic above syntax trees. It is written in “OO” style. Each type is self contained (as in, it knows its parents and full context). It should be “clean code”.
hir_*
crates are the implementation of the compiler logic.
They are written in “ECS” style, with relatively little abstractions.
Many types are not self-contained, and explicitly use local indexes, arenas, etc.
hir
is what insulates the “we don’t know how to actually write an incremental compiler”
from the ide with completions, hovers, etc. It is a (soft, internal) boundary:
https://www.tedinski.com/2018/02/06/system-boundaries.html.
Re-exports§
pub use crate::diagnostics::*;
Modules§
- Re-exports various subcrates databases so that the calling code can depend only on
hir
. This breaks abstraction boundary a bit, it would be cool if we didn’t do that. - Re-export diagnostics such that clients of
hir
don’t have to depend on low-level crates. - A map of all publicly exported items in a crate.
- MIR definitions and implementation
- Module defining all known symbols required by the rest of rust-analyzer.
- File symbol extraction.
- Term search
Structs§
- A template that the attribute input must match. Only top-level shape (
#[attr]
vs#[attr(...)]
vs#[attr = ...]
) is considered now. - Desugared attributes of an item post
cfg_attr
expansion. - Configuration options used for conditional compilation on items with
cfg
attributes. We have two kind of options in different namespaces: atomic options likeunix
, and key-value options liketarget_arch="x86"
. - hir::Crate describes a single crate. It’s the main interface with which a crate’s dependencies interact. Mostly, it should be just a proxy for the root module.
- Contains the results of (early) name resolution.
- Input to the analyzer is a set of files, where each file is identified by
FileId
and contains source code. However, another source of source code in Rust are macros: each macro can be thought of as producing a “temporary file”. To assign an id to such a file, we use the id of the macro call that produced the file. So, aHirFileId
is either aFileId
(source code written by user), or aMacroCallId
(source code produced by macro). - A wrapper around three booleans
InFile<T>
stores a value ofT
inside a particular file/syntax tree.- A single local definition.
Name
is a wrapper around string, which is used in hir for both references and declarations. In theory, names should also carry hygiene info, but we are not there yet!- Primary API to get semantic information, like types, from syntax trees.
SemanticsScope
encapsulates the notion of a scope (the set of visible names) at a particular program point.
Enums§
- A Data Type
- A Data Type
- Invariant:
inner.as_assoc_item(db).is_some()
We do not actively enforce this invariant. - A simple configuration value passed in from the outside.
- The defs which have a body.
- Subset of
ide_db::Definition
that doc links can resolve to. - Invariant:
inner.as_extern_assoc_item(db).is_some()
We do not actively enforce this invariant. - A representation of all the valid language items in Rust.
- A macro
- The defs which can be visible in the module.
- The defs which can be visible in the module.
- Whether a function is safe or not.
- For IDE only
- This is used as a key for indexing impls.
- Compare ty::Ty
- Visibility of an item, with the path resolved.
Traits§
- Trait for obtaining the defining crate of an item.
Functions§
- Inserts whitespace and replaces
$crate
in macro expansions. - Resolves the item
link
points to in the scope ofdef
.