struct Generalization<'tcx> {
    ty: Ty<'tcx>,
    needs_wf: bool,
}
Expand description

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

ty: Ty<'tcx>needs_wf: bool

If true, then the generalized type may not be well-formed, even if the source type is well-formed, so we should add an additional check to enforce that it is. This arises in particular around ‘bivariant’ type parameters that are only constrained by 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 that Foo<?A, ?B> <: Foo<?C, ?D> (or >:), we will wind up with the requirement that ?A <: ?C, but no particular relationship between ?B and ?D (after all, we do not know the variance of the normalized form of A::Item with respect to A). If we do nothing else, this may mean that ?D goes unconstrained (as in #41677). So, in this scenario where we create a new type variable in a bivariant context, we set the needs_wf flag to true. This will force the calling code to check that WF(Foo<?C, ?D>) holds, which in turn implies that ?C::Item == ?D. So once ?C is constrained, that should suffice to restrict ?D.

Trait Implementations

Formats the value using the given formatter. Read more

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more
Immutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more

Returns the argument unchanged.

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

The type returned in the event of a conversion error.
Performs the conversion.
The type returned in the event of a conversion error.
Performs the conversion.

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference’s “Type Layout” chapter for details on type layout guarantees.

Size: 16 bytes