Crate rustc_hir_analysis

Source
Expand description

§typeck

The type checker is responsible for:

  1. Determining the type of each expression.
  2. Resolving methods and traits.
  3. Guaranteeing that most type rules are met. (“Most?”, you say, “why most?” Well, dear reader, read on.)

The main entry point is check_crate(). Type checking operates in several major phases:

  1. The collect phase first passes over all items and determines their type, without examining their “innards”.

  2. Variance inference then runs to compute the variance of each parameter.

  3. Coherence checks for overlapping or orphaned impls.

  4. Finally, the check phase then checks function bodies and so forth. Within the check phase, we check each function body one at a time (bodies of function expressions are checked as part of the containing function). Inference is used to supply types wherever they are unknown. The actual checking of a function itself has several phases (check, regionck, writeback), as discussed in the documentation for the check module.

The type checker is defined into various submodules which are documented independently:

  • hir_ty_lowering: lowers type-system entities from the [HIR][hir] to the rustc_middle::ty representation.

  • collect: computes the types of each top-level item and enters them into the tcx.types table for later use.

  • coherence: enforces coherence rules, builds some tables.

  • variance: variance inference

  • outlives: outlives inference

  • check: walks over function bodies and type checks them, inferring types for local variables, type parameters, etc as necessary.

  • infer: finds the types to use for each type variable such that all subtyping and assignment constraints are met. In essence, the check module specifies the constraints, and the infer module solves them.

§Note

This API is completely unstable and subject to change.

Modules§

  • autoderef
  • bounds 🔒
    Bounds are restrictions applied to some types after they’ve been lowered from the HIR to the rustc_middle::ty form.
  • check
    typeck: check phase
  • check_unused 🔒
  • coherence 🔒
  • collect
    “Collection” is the process of determining the type and other external details of each item in Rust. Collection is specifically concerned with inter-procedural things – for example, for a function definition, collection will figure out the type and signature of the function, but it will not visit the body of the function in any way, nor examine type annotations on local variables (that’s the job of type checking).
  • constrained_generic_params 🔒
  • delegation 🔒
    Support inheriting generic parameters and predicates for function delegation.
  • errors 🔒
    Errors emitted by rustc_hir_analysis.
  • hir_ty_lowering
    HIR ty lowering: Lowers type-system entities from the [HIR][hir] to the rustc_middle::ty representation.
  • hir_wf_check
  • impl_wf_check 🔒
    This pass enforces various “well-formedness constraints” on impls. Logically, it is part of wfcheck – but we do it early so that we can stop compilation afterwards, since part of the trait matching infrastructure gets very grumpy if these conditions don’t hold. In particular, if there are type parameters that are not part of the impl, then coherence will report strange inference ambiguity errors; if impls have duplicate items, we get misleading specialization errors. These things can (and probably should) be fixed, but for the moment it’s easier to do these checks early.
  • outlives 🔒
  • variance 🔒
    Module for inferring the variance of type and lifetime parameters. See the rustc dev guide chapter for more info.

Statics§

  • DEFAULT_LOCALE_RESOURCE
    Raw content of Fluent resource for this crate, generated by fluent_messages macro, imported by rustc_driver to include all crates’ resources in one bundle.

Functions§