Enum rustc_trait_selection::traits::wf::Elaborate
source · enum Elaborate {
All,
None,
}
Expand description
Controls whether we “elaborate” supertraits and so forth on the WF predicates. This is a kind of hack to address #43784. The underlying problem in that issue was a trait structure like:
trait Foo: Copy { }
trait Bar: Foo { }
impl<T: Bar> Foo for T { }
impl<T> Bar for T { }
Here, in the Foo
impl, we will check that T: Copy
holds – but
we decide that this is true because T: Bar
is in the
where-clauses (and we can elaborate that to include T: Copy
). This wouldn’t be a problem, except that when we check the
Bar
impl, we decide that T: Foo
must hold because of the Foo
impl. And so nowhere did we check that T: Copy
holds!
To resolve this, we elaborate the WF requirements that must be
proven when checking impls. This means that (e.g.) the impl Bar for T
will be forced to prove not only that T: Foo
but also T: Copy
(which it won’t be able to do, because there is no Copy
impl for T
).
Variants§
Trait Implementations§
source§impl PartialEq<Elaborate> for Elaborate
impl PartialEq<Elaborate> for Elaborate
impl Copy for Elaborate
impl Eq for Elaborate
impl StructuralEq for Elaborate
impl StructuralPartialEq for Elaborate
Auto Trait Implementations§
impl RefUnwindSafe for Elaborate
impl Send for Elaborate
impl Sync for Elaborate
impl Unpin for Elaborate
impl UnwindSafe for Elaborate
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
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:
All
: 0 bytesNone
: 0 bytes