Struct rustc::traits::ProjectionCache

pub struct ProjectionCache<'tcx> { /* fields omitted */ }

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

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 skolemized 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.

FIXME: we probably also want some sort of cross-infcx cache here to reduce the amount of duplication. Let's see what we get with the Chalk reforms.

Methods

impl<'tcx> ProjectionCache<'tcx>

pub fn new() -> Self

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

pub fn snapshot(&mut self) -> ProjectionCacheSnapshot

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

pub fn rollback_to(&mut self, snapshot: ProjectionCacheSnapshot)

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

pub fn rollback_skolemized(&mut self, snapshot: &ProjectionCacheSnapshot)

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

pub fn commit(&mut self, snapshot: ProjectionCacheSnapshot)

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

pub fn complete(&mut self, key: ProjectionCacheKey<'tcx>)

🔬 This is a nightly-only experimental API. (rustc_private)

this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?

Mark the relevant projection cache key as having its derived obligations complete, so they won't have to be re-computed (this is OK to do in a snapshot - if the snapshot is rolled back, the obligations will be marked as incomplete again).