Enum rustc_trait_selection::traits::select::SelectionCandidate

source ·

pub enum SelectionCandidate<'tcx> {
Show 16 variants    BuiltinCandidate {
        has_nested: bool,
    },
    TransmutabilityCandidate,
    ParamCandidate(Binder<'tcx, TraitPredicate<'tcx>>),
    ImplCandidate(DefId),
    AutoImplCandidate,
    ProjectionCandidate(usize, BoundConstness),
    ClosureCandidate {
        is_const: bool,
    },
    GeneratorCandidate,
    FutureCandidate,
    FnPointerCandidate {
        is_const: bool,
    },
    TraitAliasCandidate,
    ObjectCandidate(usize),
    TraitUpcastingUnsizeCandidate(usize),
    BuiltinObjectCandidate,
    BuiltinUnsizeCandidate,
    ConstDestructCandidate(Option<DefId>),
}

Expand description

The selection process begins by considering all impls, where clauses, and so forth that might resolve an obligation. Sometimes we’ll be able to say definitively that (e.g.) an impl does not apply to the obligation: perhaps it is defined for usize but the obligation is for i32. In that case, we drop the impl out of the list. But the other cases are considered candidates.

For selection to succeed, there must be exactly one matching candidate. If the obligation is fully known, this is guaranteed by coherence. However, if the obligation contains type parameters or variables, there may be multiple such impls.

It is not a real problem if multiple matching impls exist because of type variables - it just means the obligation isn’t sufficiently elaborated. In that case we report an ambiguity, and the caller can try again after more type information has been gathered or report a “type annotations needed” error.

However, with type parameters, this can be a real problem - type parameters don’t unify with regular types, but they can unify with variables from blanket impls, and (unless we know its bounds will always be satisfied) picking the blanket impl will be wrong for at least some substitutions. To make this concrete, if we have

trait AsDebug { type Out: fmt::Debug; fn debug(self) -> Self::Out; }
impl<T: fmt::Debug> AsDebug for T {
    type Out = T;
    fn debug(self) -> fmt::Debug { self }
}
fn foo<T: AsDebug>(t: T) { println!("{:?}", <T as AsDebug>::debug(t)); }

we can’t just use the impl to resolve the <T as AsDebug> obligation – a type from another crate (that doesn’t implement fmt::Debug) could implement AsDebug.

Because where-clauses match the type exactly, multiple clauses can only match if there are unresolved variables, and we can mostly just report this ambiguity in that case. This is still a problem - we can’t do anything with ambiguities that involve only regions. This is issue #21974.

If a single where-clause matches and there are no inference variables left, then it definitely matches and we can just select it.

In fact, we even select the where-clause when the obligation contains inference variables. The can lead to inference making “leaps of logic”, for example in this situation:

pub trait Foo<T> { fn foo(&self) -> T; }
impl<T> Foo<()> for T { fn foo(&self) { } }
impl Foo<bool> for bool { fn foo(&self) -> bool { *self } }

pub fn foo<T>(t: T) where T: Foo<bool> {
    println!("{:?}", <T as Foo<_>>::foo(&t));
}
fn main() { foo(false); }

Here the obligation <T as Foo<$0>> can be matched by both the blanket impl and the where-clause. We select the where-clause and unify $0=bool, so the program prints “false”. However, if the where-clause is omitted, the blanket impl is selected, we unify $0=(), and the program prints “()”.

Exactly the same issues apply to projection and object candidates, except that we can have both a projection candidate and a where-clause candidate for the same obligation. In that case either would do (except that different “leaps of logic” would occur if inference variables are present), and we just pick the where-clause. This is, for example, required for associated types to work in default impls, as the bounds are visible both as projection bounds and as where-clauses from the parameter environment.

Variants§

§

BuiltinCandidate

Fields

§has_nested: bool

false if there are no further obligations.

A builtin implementation for some specific traits, used in cases where we cannot rely an ordinary library implementations.

The most notable examples are sized, Copy and Clone. This is also used for the DiscriminantKind and Pointee trait, both of which have an associated type.

§

TransmutabilityCandidate

Implementation of transmutability trait.

§

ProjectionCandidate(usize, BoundConstness)

This is a trait matching with a projected type as Self, and we found an applicable bound in the trait definition. The usize is an index into the list returned by tcx.item_bounds. The constness is the constness of the bound in the trait.

§

ClosureCandidate

Fields

§is_const: bool

Implementation of a Fn-family trait by one of the anonymous types generated for an || expression.

§

GeneratorCandidate

Implementation of a Generator trait by one of the anonymous types generated for a generator.

§

FutureCandidate

Implementation of a Future trait by one of the generator types generated for an async construct.

§

FnPointerCandidate

Fields

§is_const: bool

Implementation of a Fn-family trait by one of the anonymous types generated for a fn pointer type (e.g., fn(int) -> int)

§

TraitAliasCandidate

§

ObjectCandidate(usize)

Matching dyn Trait with a supertrait of Trait. The index is the position in the iterator returned by rustc_infer::traits::util::supertraits.

§

TraitUpcastingUnsizeCandidate(usize)

Perform trait upcasting coercion of dyn Trait to a supertrait of Trait. The index is the position in the iterator returned by rustc_infer::traits::util::supertraits.

§