-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Incorrect "associated type must be specified" for trait objects #23856
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Very strange. I'd expect the |
(comment copied from duplicate #36978 for locality purposes, since it contains a more-M WE) Consider the following: trait Foo { type FooT; }
trait Bar { }
trait FooBar: Foo<FooT=usize> + Bar { }
type BoxedFooBar = Box<FooBar>; Since the value of
To make it compile, one must duplicate the information at every use-site: trait Foo { type FooT; }
trait Bar { }
trait FooBar: Foo<FooT=usize> + Bar { }
type BoxedFooBar = Box<FooBar<FooT=usize>>; |
Am I looking at an example of this, or something else entirely? Playground example; that fails to compile with the same error as above in this thread. (Note that this example contains an error on my part: I intended to use the template parameter |
Yes, this is the same thing. |
Just ran into this today. As mentioned by @thanatos and in some linked duplicates, it appears to only impact trait objects. (if it impacted generic type parameters, I think there would be a lot more fuss over it!) trait MyFunc: FnMut() {}
impl<F:FnMut()> MyFunc for F {}
// OK
fn takes_generic<F: MyFunc>(mut f: F) { f(); }
// Error: missing associated type `Output` value
fn takes_trait_object(f: &mut MyFunc) { f(); }
fn main() {} Changing the trait object to a generic type parameter is a workaround in many, but not all, use cases. |
Just ran into this bug while trying to mix |
I ran into the same bug, in the same situation like @vorot93. |
I ran into that problem too, it's quite annoying. I hope a fix will pop soon. |
Any progress on this lately? |
Take supertraits into account when calculating associated types Fixes rust-lang#24010 and rust-lang#23856. Applies to trait aliases too. As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See rust-lang#50589 for more info. I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+. N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this. CC @carllerche @theemathas @durka @mbrubeck
I think this issue has been resolved as of PR #55687, correct? The linked playgrounds no longer fail to compile, at least on a cursory inspection. Could we close this issue out? |
Looks fixed to me. |
The workaround for rust-lang/rust#23856 can now be removed.
Uh oh!
There was an error while loading. Please reload this page.
Code:
Error:
playpen
I expect this code to compile without errors.
EDIT
This is the error on the current version:
Changing line 6 to
data: Box<MyIterator<Item=char> + 'static>,
moves the error to line 11:However, commenting line 11 and uncommenting line 13 makes the code compile fine.
The text was updated successfully, but these errors were encountered: