Crate rustc_hir

source ·
Expand description

HIR datatypes. See the rustc dev guide for more info.

Re-exports§

Modules§

  • arena 🔒
  • For each definition, we track the following data. A definition here is defined somewhat circularly as “something with a DefId”, but it generally corresponds to things like structs, enums, etc. There are also some rather random cases (like const initializer expressions) that are mostly just leftovers.
  • hir 🔒
  • HIR walker for walking the contents of nodes.
  • Defines lang items.
  • target 🔒
    This module implements some validity checks for attributes. In particular it verifies that #[inline] and #[repr] attributes are attached to items that actually support them and if there are conflicts between multiple such attributes attached to the same item.
  • Validity checking for weak lang items

Macros§

  • This higher-order macro declares a list of types which can be allocated by Arena. Note that all Copy types can be allocated by default and need not be specified here.

Structs§

  • A constant (expression) that’s not an item or associated item, but needs its own DefId for type-checking, const-eval, etc. These are usually found nested inside types (e.g., array lengths) or expressions (e.g., repeat counts), and also used to define explicit discriminant values for enum variants.
  • Represents a single arm of a match expression, e.g. <pat> (if <guard>) => <body>.
  • A constraint on an associated item.
  • Attributes owned by a HIR owner.
  • The mode of a binding (mut, ref mut, etc). Used for both the explicit binding annotations given in the HIR for a binding and the final binding mode that we infer after type inference/match ergonomics. .0 is the by-reference mode (ref, ref mut, or by value), .1 is the mutability of the binding.
  • A block of statements { .. }, which may have a label (in this case the targeted_by_break field will be true) and may be unsafe by means of the rules being anything but DefaultBlock.
  • The body of a function, closure, or constant value. In the case of a function, the body contains not only the function body itself (which is an expression), but also the argument patterns, since those are something that the caller doesn’t really care about.
  • A constant that enters the type system, used for arguments to const generics (e.g. array lengths).
  • An inline constant expression const { something }.
  • The top-level data structure that stores the entire contents of the crate currently being compiled.
  • An expression.
  • Represents the header (not the body) of a function declaration.
  • Represents a function’s signature in a trait declaration, trait implementation, or a free function.
  • A reference from a foreign block to one of its items. This contains the item’s ID, naturally, but also the item’s name and some other high-level details (like whether it is an associated type or method, and whether it is public). This allows other passes to find the impl they want without loading the ID (which means fewer edges in the incremental compilation graph).
  • The generic arguments and associated item constraints of a path segment.
  • Represents lifetimes and type parameters attached to a declaration of a function, enum, trait, etc.
  • Represents an impl block declaration.
  • Represents an associated item within an impl block.
  • A reference from an impl to one of its associated items. This contains the item’s ID, naturally, but also the item’s name and some other high-level details (like whether it is an associated type or method, and whether it is public). This allows other passes to find the impl they want without loading the ID (which means fewer edges in the incremental compilation graph).
  • An item
  • Represents a let <pat>[: <ty>] = <expr> expression (not a LetStmt), occurring in an if-let or let-else, evaluating to a boolean. Typically the pattern is refutable.
  • Represents a let statement (i.e., let <pat>:<ty> = <init>;).
  • Full information resulting from lowering an AST node.
  • Map of all HIR nodes inside the current owner. These nodes are mapped by ItemLocalId alongside the index of their parent node. The HIR tree, including bodies, is pre-hashed.
  • Represents a parameter in a function header.
  • HIR node coupled with its parent’s id in the same HIR owner.
  • A single field in a struct pattern.
  • A Path is essentially Rust’s notion of a name; for instance, std::cmp::PartialEq. It’s represented as a sequence of identifiers, along with a bunch of supporting information.
  • A segment of a path: an identifier, an optional lifetime, and a set of types.
  • We need to have a Node for the HirId that we attach the type/const param resolution to. Lifetimes don’t have this problem, and for them, it’s actually kind of detrimental to use a custom node type versus just using Lifetime, since resolve_bound_vars operates on Lifetimes.
  • A statement.
  • Represents an item declaration within a trait declaration, possibly including a default implementation. A trait item is either required (meaning it doesn’t have an implementation, just a signature) or provided (meaning it has a default implementation).
  • A reference from an trait to one of its associated items. This contains the item’s id, naturally, but also the item’s name and some other high-level details (like whether it is an associated type or method, and whether it is public). This allows other passes to find the impl they want without loading the ID (which means fewer edges in the incremental compilation graph).
  • References to traits in impls.
  • A variable captured by a closure.
  • A type bound (e.g., for<'c> Foo: Send + Clone + 'c).
  • An equality predicate (e.g., T = int); currently unsupported.
  • A lifetime predicate (e.g., 'a: 'b + 'c).

Enums§

Traits§

  • Requirements for a StableHashingContext to be used in this crate. This is a hack to allow using the HashStable_Generic derive macro instead of implementing everything in rustc_middle.

Functions§

  • Checks if the specified expression is a built-in range literal. (See: LoweringContext::lower_expr()).

Type Aliases§