Struct Generalization

struct Generalization<T> {
    pub value_may_be_infer: T,
    pub has_unconstrained_ty_var: bool,
}

Result from a generalization operation. This includes not only the generalized type, but also a bool flag indicating whether further WF checks are needed.

Fields

value_may_be_infer: T

When generalizing <?0 as Trait>::Assoc or <T as Bar<<?0 as Foo>::Assoc>>::Assoc for ?0 generalization returns an inference variable.

This has to be handled wotj care as it can otherwise very easily result in infinite recursion.

has_unconstrained_ty_var: bool

In general, we do not check whether all types which occur during type checking are well-formed. We only check wf of user-provided types and when actually using a type, e.g. for method calls.

This means that when subtyping, we may end up with unconstrained inference variables if a generalized type has bivariant parameters. A parameter may only be bivariant if it is constrained by a projection bound in a where-clause. As an example, imagine a type:

struct Foo<A, B> where A: Iterator<Item = B> {
    data: A
}

here, A will be covariant, but B is unconstrained.

However, whatever it is, for Foo to be WF, it must be equal to A::Item. If we have an input Foo<?A, ?B>, then after generalization we will wind up with a type like Foo<?C, ?D>. When we enforce Foo<?A, ?B> <: Foo<?C, ?D>, we will wind up with the requirement that ?A <: ?C, but no particular relationship between ?B and ?D (after all, these types may be completely different). If we do nothing else, this may mean that ?D goes unconstrained (as in #41677). To avoid this we emit a WellFormed obligation in these cases.

Trait Implementations

impl<T: Debug> Debug for Generalization<T>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

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.