pub enum EvaluationResult {
EvaluatedToOk,
EvaluatedToOkModuloRegions,
EvaluatedToOkModuloOpaqueTypes,
EvaluatedToAmbig,
EvaluatedToUnknown,
EvaluatedToRecur,
EvaluatedToErr,
}
Expand description
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.
Auto Trait Implementations§
impl RefUnwindSafe for EvaluationResult
impl Send for EvaluationResult
impl Sync for EvaluationResult
impl Unpin for EvaluationResult
impl UnwindSafe for EvaluationResult
Blanket Implementations§
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 bytesEvaluatedToOkModuloRegions
: 0 bytesEvaluatedToOkModuloOpaqueTypes
: 0 bytesEvaluatedToAmbig
: 0 bytesEvaluatedToUnknown
: 0 bytesEvaluatedToRecur
: 0 bytesEvaluatedToErr
: 0 bytes