Canonicalization is the key to constructing a query in the
middle of type inference. Ordinarily, it is not possible to store
types from type inference in query keys, because they contain
references to inference variables whose lifetimes are too short
and so forth. Canonicalizing a value T1 using
produces two things:
- a value T2 where each unbound inference variable has been replaced with a canonical variable;
- a map M (of type
CanonicalVarValues) from those canonical variables back to the original.
We can then do queries using T2. These will give back constraints
on the canonical variables which can be translated, using the map
M, into constraints in our source context. This process of
translating the results back is done by the
For a more detailed look at what is happening here, check out the chapter in the rustc dev guide.
A “canonicalized” type
Information about a canonical variable that is included with the canonical value. This is sufficient information for code to create a copy of the canonical value in some other inference context, with fresh inference variables replacing the canonical values.
A set of values corresponding to the canonical variables from some
When we canonicalize a value to form a query, we wind up replacing various parts of it with canonical variables. This struct stores those replaced bits to remember for when we process the query result.
After we execute a query with a canonicalized key, we get back a
Rust actually has more than one category of type variables; notably, the type variables we create for literals (e.g., 22 or 22.) can only be instantiated with integral/float types (e.g., usize or f32). In order to faithfully reproduce a type, we need to know what set of types a given type variable can be unified with.
Describes the “kind” of the canonical variable. This is a “kind” in the type-theory sense of the term – i.e., a “meta” type system that analyzes type-like values.
Indicates whether or not we were able to prove the query to be true.