The type checker is responsible for:
- Determining the type of each expression.
- Resolving methods and traits.
- 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:
The collect phase first passes over all items and determines their type, without examining their “innards”.
Variance inference then runs to compute the variance of each parameter.
Coherence checks for overlapping or orphaned impls.
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
The type checker is defined into various submodules which are documented independently:
astconv: converts the AST representation of types into the
collect: computes the types of each top-level item and enters them into the
tcx.typestable 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.
This API is completely unstable and subject to change.
- Conversion from AST representation of types to the
ty.rsrepresentation. The main routine here is
ast_ty_to_ty(); each use is parameterized by an instance of
- bounds 🔒Bounds are restrictions applied to some types after they’ve been converted into the
tyform from the HIR.
- typeck: check phase
- “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).
- errors 🔒Errors emitted by
- 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.
- Raw content of Fluent resource for this crate, generated by
fluent_messagesmacro, imported by
rustc_driverto include all crates’ resources in one bundle.
- A quasi-deprecated helper used in rustdoc and clippy to get the type from a HIR node.