Struct rustc_trait_selection::infer::region_constraints::RegionConstraintStorage

pub struct RegionConstraintStorage<'tcx> {
    var_infos: IndexVec<RegionVid, RegionVariableInfo>,
    data: RegionConstraintData<'tcx>,
    lubs: HashMap<TwoRegions<'tcx>, RegionVid, BuildHasherDefault<FxHasher>>,
    glbs: HashMap<TwoRegions<'tcx>, RegionVid, BuildHasherDefault<FxHasher>>,
    pub(super) unification_table: UnificationTable<InPlace<RegionVid, Vec<VarValue<RegionVid>, Global>, ()>>,
    any_unifications: bool,
}

Fields

var_infos: IndexVec<RegionVid, RegionVariableInfo>

For each RegionVid, the corresponding RegionVariableOrigin.

data: RegionConstraintData<'tcx>

lubs: HashMap<TwoRegions<'tcx>, RegionVid, BuildHasherDefault<FxHasher>>

For a given pair of regions (R1, R2), maps to a region R3 that is designated as their LUB (edges R1 <= R3 and R2 <= R3 exist). This prevents us from making many such regions.

glbs: HashMap<TwoRegions<'tcx>, RegionVid, BuildHasherDefault<FxHasher>>

For a given pair of regions (R1, R2), maps to a region R3 that is designated as their GLB (edges R3 <= R1 and R3 <= R2 exist). This prevents us from making many such regions.

unification_table: UnificationTable<InPlace<RegionVid, Vec<VarValue<RegionVid>, Global>, ()>>

When we add a R1 == R2 constriant, we currently add (a) edges R1 <= R2 and R2 <= R1 and (b) we unify the two regions in this table. You can then call opportunistic_resolve_var early which will map R1 and R2 to some common region (i.e., either R1 or R2). This is important when fulfillment, dropck and other such code is iterating to a fixed point, because otherwise we sometimes would wind up with a fresh stream of region variables that have been equated but appear distinct.

any_unifications: bool

a flag set to true when we perform any unifications; this is used to micro-optimize take_and_reset_data