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 it’s 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:
pub use crate::diagnostics::AddReferenceHere;
pub use crate::diagnostics::AnyDiagnostic;
pub use crate::diagnostics::BreakOutsideOfLoop;
pub use crate::diagnostics::InactiveCode;
pub use crate::diagnostics::MacroError;
pub use crate::diagnostics::MismatchedArgCount;
pub use crate::diagnostics::MissingFields;
pub use crate::diagnostics::MissingMatchArms;
pub use crate::diagnostics::MissingOkOrSomeInTailExpr;
pub use crate::diagnostics::MissingUnsafe;
pub use crate::diagnostics::NoSuchField;
pub use crate::diagnostics::RemoveThisSemicolon;
pub use crate::diagnostics::ReplaceFilterMapNextWithFindMap;
pub use crate::diagnostics::UnimplementedBuiltinMacro;
pub use crate::diagnostics::UnresolvedExternCrate;
pub use crate::diagnostics::UnresolvedImport;
pub use crate::diagnostics::UnresolvedMacroCall;
pub use crate::diagnostics::UnresolvedModule;
pub use crate::diagnostics::UnresolvedProcMacro;
Re-exports various subcrates databases so that the calling code can depend
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
A map of all publicly exported items in a crate.
Configuration options used for conditional compilation on items with
We have two kind of options in different namespaces: atomic options like
key-value options like
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.
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, a
HirFileId is either a
FileId (source code
written by user), or a
MacroCallId (source code produced by macro).
InFile<T> stores a value of
T inside a particular file/syntax tree.
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.
SemanticScope encapsulates the notion of a scope (the set of visible
names) at a particular program point.
A Data Type
We do not actively enforce this invariant.
A simple configuration value passed in from the outside.
The defs which have a body.
The defs which can be visible in the module.
For IDE only
Visibility of an item, with the path resolved.