Struct rustc_trait_selection::infer::type_variable::TypeVariableStorage

pub struct TypeVariableStorage<'tcx> {
    pub(in infer::type_variable) values: SnapshotVec<Delegate, Vec<<Delegate as SnapshotVecDelegate>::Value>, ()>,
    pub(in infer::type_variable) eq_relations: UnificationTable<InPlace<TyVidEqKey<'tcx>, Vec<VarValue<TyVidEqKey<'tcx>>>, ()>>,
    pub(in infer::type_variable) sub_relations: UnificationTable<InPlace<TyVid, Vec<VarValue<TyVid>>, ()>>,
}

Fields

values: SnapshotVec<Delegate, Vec<<Delegate as SnapshotVecDelegate>::Value>, ()>

eq_relations: UnificationTable<InPlace<TyVidEqKey<'tcx>, Vec<VarValue<TyVidEqKey<'tcx>>>, ()>>

Two variables are unified in eq_relations when we have a constraint ?X == ?Y. This table also stores, for each key, the known value.

sub_relations: UnificationTable<InPlace<TyVid, Vec<VarValue<TyVid>>, ()>>

Two variables are unified in sub_relations when we have a constraint ?X <: ?Y or a constraint ?Y <: ?X. This second table exists only to help with the occurs check. In particular, we want to report constraints like these as an occurs check violation:

?1 <: ?3
Box<?3> <: ?1

This works because ?1 and ?3 are unified in the sub_relations relation (not in eq_relations). Then when we process the Box<?3> <: ?1 constraint, we do an occurs check on Box<?3> and find a potential cycle.

This is reasonable because, in Rust, subtypes have the same "skeleton" and hence there is no possible type such that (e.g.) Box<?3> <: ?3 for any ?3.