Struct SolverRelating 

pub struct SolverRelating<'infcx, Infcx, I: Interner> {
    infcx: &'infcx Infcx,
    structurally_relate_aliases: StructurallyRelateAliases,
    param_env: I::ParamEnv,
    span: I::Span,
    ambient_variance: Variance,
    goals: Vec<Goal<I, I::Predicate>>,
    cache: DelayedSet<(Variance, I::Ty, I::Ty)>,
}

Enforce that a is equal to or a subtype of b.

Fields

infcx: &'infcx Infcx

structurally_relate_aliases: StructurallyRelateAliases

param_env: I::ParamEnv

span: I::Span

ambient_variance: Variance

goals: Vec<Goal<I, I::Predicate>>

cache: DelayedSet<(Variance, I::Ty, I::Ty)>

The cache only tracks the ambient_variance as it’s the only field which is mutable and which meaningfully changes the result when relating types.

The cache does not track whether the state of the Infcx has been changed or whether we’ve added any goals to self.goals. Whether a goal is added once or multiple times is not really meaningful.

Changes in the inference state may delay some type inference to the next fulfillment loop. Given that this loop is already necessary, this is also not a meaningful change. Consider the following three relations:

Vec<?0> sub Vec<?1>
?0 eq u32
Vec<?0> sub Vec<?1>

Without a cache, the second Vec<?0> sub Vec<?1> would eagerly constrain ?1 to u32. When using the cache entry from the first time we’ve related these types, this only happens when later proving the Subtype(?0, ?1) goal from the first relation.

Implementations

impl<'infcx, Infcx, I> SolverRelating<'infcx, Infcx, I>

where Infcx: InferCtxtLike<Interner = I>, I: Interner,

pub fn new( infcx: &'infcx Infcx, structurally_relate_aliases: StructurallyRelateAliases, ambient_variance: Variance, param_env: I::ParamEnv, span: I::Span, ) -> Self

Trait Implementations

impl<Infcx, I> PredicateEmittingRelation<Infcx> for SolverRelating<'_, Infcx, I>

where Infcx: InferCtxtLike<Interner = I>, I: Interner,

fn span(&self) -> I::Span

fn param_env(&self) -> I::ParamEnv

fn structurally_relate_aliases(&self) -> StructurallyRelateAliases

Whether aliases should be related structurally. This is pretty much always No unless you’re equating in some specific locations of the new solver. See the comments in these use-cases for more details.

fn register_predicates( &mut self, obligations: impl IntoIterator<Item: Upcast<I, I::Predicate>>, )

Register predicates that must hold in order for this relation to hold. This uses the default param_env of the obligation.

fn register_goals( &mut self, obligations: impl IntoIterator<Item = Goal<I, I::Predicate>>, )

Register obligations that must hold in order for this relation to hold

fn register_alias_relate_predicate(&mut self, a: I::Ty, b: I::Ty)

Register AliasRelate obligation(s) that both types must be related to each other.

impl<Infcx, I> TypeRelation<I> for SolverRelating<'_, Infcx, I>

where Infcx: InferCtxtLike<Interner = I>, I: Interner,

fn cx(&self) -> I

fn relate_item_args( &mut self, item_def_id: I::DefId, a_arg: I::GenericArgs, b_arg: I::GenericArgs, ) -> RelateResult<I, I::GenericArgs>

Relate the two args for the given item. The default is to look up the variance for the item and proceed accordingly.

fn relate_with_variance<T: Relate<I>>( &mut self, variance: Variance, _info: VarianceDiagInfo<I>, a: T, b: T, ) -> RelateResult<I, T>

Switch variance for the purpose of relating a and b.

fn tys(&mut self, a: I::Ty, b: I::Ty) -> RelateResult<I, I::Ty>

fn regions(&mut self, a: I::Region, b: I::Region) -> RelateResult<I, I::Region>

fn consts(&mut self, a: I::Const, b: I::Const) -> RelateResult<I, I::Const>

fn binders<T>( &mut self, a: Binder<I, T>, b: Binder<I, T>, ) -> RelateResult<I, Binder<I, T>>

where T: Relate<I>,

fn relate<T: Relate<I>>(&mut self, a: T, b: T) -> RelateResult<I, T>

Generic relation routine suitable for most anything.

Layout

Note: Unable to compute type layout, possibly due to this type having generic parameters. Layout can only be computed for concrete, fully-instantiated types.