Struct rustc_trait_selection::infer::type_variable::TypeVariableStorage [−][src]
pub struct TypeVariableStorage<'tcx> {
values: SnapshotVec<Delegate, Vec<TypeVariableData, Global>, ()>,
eq_relations: UnificationTable<InPlace<TyVidEqKey<'tcx>, Vec<VarValue<TyVidEqKey<'tcx>>, Global>, ()>>,
sub_relations: UnificationTable<InPlace<TyVid, Vec<VarValue<TyVid>, Global>, ()>>,
}Fields
values: SnapshotVec<Delegate, Vec<TypeVariableData, Global>, ()>eq_relations: UnificationTable<InPlace<TyVidEqKey<'tcx>, Vec<VarValue<TyVidEqKey<'tcx>>, Global>, ()>>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>, Global>, ()>>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.
Auto Trait Implementations
impl<'tcx> !RefUnwindSafe for TypeVariableStorage<'tcx>
impl<'tcx> !Send for TypeVariableStorage<'tcx>
impl<'tcx> !Sync for TypeVariableStorage<'tcx>
impl<'tcx> Unpin for TypeVariableStorage<'tcx>
impl<'tcx> !UnwindSafe for TypeVariableStorage<'tcx>
Blanket Implementations
Layout
Note: Most layout information is completely unstable and may be different between compiler versions and platforms. The only exception is types with certain repr(...) attributes. Please see the Rust Reference’s “Type Layout” chapter for details on type layout guarantees.
Size: 72 bytes