Enum rustc_trait_selection::traits::select::EvaluationResult

pub enum EvaluationResult {
    EvaluatedToOk,
    EvaluatedToOkModuloRegions,
    EvaluatedToOkModuloOpaqueTypes,
    EvaluatedToAmbig,
    EvaluatedToUnknown,
    EvaluatedToRecur,
    EvaluatedToErr,
}

The result of trait evaluation. The order is important here as the evaluation of a list is the maximum of the evaluations.

The evaluation results are ordered: - EvaluatedToOk implies EvaluatedToOkModuloRegions implies EvaluatedToAmbig implies EvaluatedToUnknown - EvaluatedToErr implies EvaluatedToRecur - the “union” of evaluation results is equal to their maximum - all the “potential success” candidates can potentially succeed, so they are noops when unioned with a definite error, and within the categories it’s easy to see that the unions are correct.

Variants

EvaluatedToOk

Evaluation successful.

EvaluatedToOkModuloRegions

Evaluation successful, but there were unevaluated region obligations.

EvaluatedToOkModuloOpaqueTypes

Evaluation successful, but need to rerun because opaque types got hidden types assigned without it being known whether the opaque types are within their defining scope

EvaluatedToAmbig

Evaluation is known to be ambiguous – it might hold for some assignment of inference variables, but it might not.

While this has the same meaning as EvaluatedToUnknown – we can’t know whether this obligation holds or not – it is the result we would get with an empty stack, and therefore is cacheable.

EvaluatedToUnknown

Evaluation failed because of recursion involving inference variables. We are somewhat imprecise there, so we don’t actually know the real result.

This can’t be trivially cached for the same reason as EvaluatedToRecur.

EvaluatedToRecur

Evaluation failed because we encountered an obligation we are already trying to prove on this branch.

We know this branch can’t be a part of a minimal proof-tree for the “root” of our cycle, because then we could cut out the recursion and maintain a valid proof tree. However, this does not mean that all the obligations on this branch do not hold – it’s possible that we entered this branch “speculatively”, and that there might be some other way to prove this obligation that does not go through this cycle – so we can’t cache this as a failure.

For example, suppose we have this:

pub trait Trait { fn xyz(); }
// This impl is "useless", but we can still have
// an `impl Trait for SomeUnsizedType` somewhere.
impl<T: Trait + Sized> Trait for T { fn xyz() {} }

pub fn foo<T: Trait + ?Sized>() {
    <T as Trait>::xyz();
}

When checking foo, we have to prove T: Trait. This basically translates into this:

(T: Trait + Sized →_\impl T: Trait), T: Trait ⊢ T: Trait

When we try to prove it, we first go the first option, which recurses. This shows us that the impl is “useless” – it won’t tell us that T: Trait unless it already implemented Trait by some other means. However, that does not prevent T: Trait does not hold, because of the bound (which can indeed be satisfied by SomeUnsizedType from another crate).

EvaluatedToErr

Evaluation failed.

Trait Implementations

impl From<TreatInductiveCycleAs> for EvaluationResult

fn from(treat: TreatInductiveCycleAs) -> EvaluationResult

Converts to this type from the input type.

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: 1 byte

Size for each variant:

• EvaluatedToOk: 0 bytes
• EvaluatedToOkModuloRegions: 0 bytes
• EvaluatedToOkModuloOpaqueTypes: 0 bytes
• EvaluatedToAmbig: 0 bytes
• EvaluatedToUnknown: 0 bytes
• EvaluatedToRecur: 0 bytes
• EvaluatedToErr: 0 bytes