You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bogus associated type in associated type bound compiles #21259
use std::ops::Deref;structFoo<T>{xs:[T;0]}impl<T>DerefforFoo<T>{typeTarget = [T];fnderef(&self) -> <SelfasDeref>::WhyDoesThisCompile{123}}fnmain(){}
This (and the example in the original report) compiles today with rustc 1.0.0-nightly (3ef8ff1f8 2015-02-12 00:38:24 +0000). In fact, the body of the deref function can be whatever type you fancy, and same goes for the type of Target, it doesn't matter. If you try to use the deref on a value, though, you get this lovely ICE:
If you make Foo non-generic, then the same ICE happens even without actually deref-ing a Foo value, which suggests the generic type has to be instantiated before any problems arise.
Discussed with @nikomatsakis today. We agreed that there are (at least) two distinct bugs being illustrated here, as is somewhat implied in the description.
I have a fix for the <Type as Trait>::NoExist issue. I will file a separate bug just for that, and then put up the pull request sometime afterward.
Oddly enough, our stdlib seems to be taking slight advantage of this bug: fn cloned in core::iter refers to the projected type <Self::Item as Deref>::Output, but the Deref trait's associated item is named Target.
Which raises the question: How was/is this currently working? In the playpen, I was not able to demonstrate any actual hole in the library via this mistake; i.e. calling .cloned() on an iterator over non-cloneables is still rejected. But why/how does it make the connection to reject the code here? (Or is this a sign that my own checking code is too strict, and what the core library is currently doing is somehow legal Rust? Or is there some other associated type named Output, but for a different trait, attached to Self in the case I was testing?)
Activity
tomjakubowski commentedon Feb 13, 2015
This (and the example in the original report) compiles today with
rustc 1.0.0-nightly (3ef8ff1f8 2015-02-12 00:38:24 +0000). In fact, the body of thedereffunction can be whatever type you fancy, and same goes for the type ofTarget, it doesn't matter. If you try to use the deref on a value, though, you get this lovely ICE:If you make
Foonon-generic, then the same ICE happens even without actually deref-ing aFoovalue, which suggests the generic type has to be instantiated before any problems arise.pnkfelix commentedon Feb 19, 2015
Not a 1.0 blocker; assigning P-high.
pnkfelix commentedon Feb 23, 2015
Discussed with @nikomatsakis today. We agreed that there are (at least) two distinct bugs being illustrated here, as is somewhat implied in the description.
I have a fix for the
<Type as Trait>::NoExistissue. I will file a separate bug just for that, and then put up the pull request sometime afterward.Oddly enough, our stdlib seems to be taking slight advantage of this bug:
fn clonedincore::iterrefers to the projected type<Self::Item as Deref>::Output, but theDereftrait's associated item is namedTarget.Which raises the question: How was/is this currently working? In the playpen, I was not able to demonstrate any actual hole in the library via this mistake; i.e. calling
.cloned()on an iterator over non-cloneables is still rejected. But why/how does it make the connection to reject the code here? (Or is this a sign that my own checking code is too strict, and what the core library is currently doing is somehow legal Rust? Or is there some other associated type namedOutput, but for a different trait, attached toSelfin the case I was testing?)arielb1 commentedon Jul 7, 2015
This is fixed, and has tests.
bluss commentedon Jul 7, 2015
Thanks!