Struct rustc_trait_selection::traits::ProjectionCache

pub struct ProjectionCache<'a, 'tcx> {
    pub(in traits::project) map: &'a mut SnapshotMap<ProjectionCacheKey<'tcx>, ProjectionCacheEntry<'tcx>, HashMap<ProjectionCacheKey<'tcx>, ProjectionCacheEntry<'tcx>, BuildHasherDefault<FxHasher>>, ()>,
    pub(in traits::project) undo_log: &'a mut InferCtxtUndoLogs<'tcx>,
}

The projection cache. Unlike the standard caches, this can include infcx-dependent type variables, therefore we have to roll the cache back each time we roll a snapshot back, to avoid assumptions on yet-unresolved inference variables. Types with placeholder regions also have to be removed when the respective snapshot ends.

Because of that, projection cache entries can be "stranded" and left inaccessible when type variables inside the key are resolved. We make no attempt to recover or remove "stranded" entries, but rather let them be (for the lifetime of the infcx).

Entries in the projection cache might contain inference variables that will be resolved by obligations on the projection cache entry (e.g., when a type parameter in the associated type is constrained through an "RFC 447" projection on the impl).

When working with a fulfillment context, the derived obligations of each projection cache entry will be registered on the fulfillcx, so any users that can wait for a fulfillcx fixed point need not care about this. However, users that don't wait for a fixed point (e.g., trait evaluation) have to resolve the obligations themselves to make sure the projected result is ok and avoid issues like #43132.

If that is done, after evaluation the obligations, it is a good idea to call ProjectionCache::complete to make sure the obligations won't be re-evaluated and avoid an exponential worst-case.

Fields

map: &'a mut SnapshotMap<ProjectionCacheKey<'tcx>, ProjectionCacheEntry<'tcx>, HashMap<ProjectionCacheKey<'tcx>, ProjectionCacheEntry<'tcx>, BuildHasherDefault<FxHasher>>, ()>

undo_log: &'a mut InferCtxtUndoLogs<'tcx>