Repository navigation
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-trait-systemArea: Trait systemArea: Trait systemC-bugCategory: This is a bug.Category: This is a bug.D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.F-arbitrary_self_types`#![feature(arbitrary_self_types)]``#![feature(arbitrary_self_types)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
I have a simple program below that is trying to call poll_next on a T: Stream. The compiler seems to ignore the trait bound, and suggests adding the exact trait bound that is already in use.
This is using the current beta rust version:
rustc 1.39.0-beta.5 (fa5c2f3e5 2019-10-02)
pub struct StreamForwarder<T> {
upstream: T,
}
impl<T: futures_core::stream::Stream> Stream for StreamForwarder<T> {
type Item = ();
fn poll_next(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>> {
self.upstream.poll_next()
}
}error[E0599]: no method named `poll_next` found for type `T` in the current scope
--> src/main.rs:13:23
|
13 | self.upstream.poll_next()
| ^^^^^^^^^ method not found in `T`
|
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following trait defines an item `poll_next`, perhaps you need to restrict type parameter `T` with it:
|
9 | impl<T: futures_core::stream::Stream + futures_core::stream::Stream> Stream for StreamForwarder<T> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0599`.
error: could not compile `poll_next_bug`.
A complete git repo reproducing the issue is here: https://github.com/fuchsnj/poll_next_bug
(remember to run rustup override set beta)
Reacted by Fenhl, Michael Snoyman, Zack Angelo and InAnYan
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-trait-systemArea: Trait systemArea: Trait systemC-bugCategory: This is a bug.Category: This is a bug.D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.F-arbitrary_self_types`#![feature(arbitrary_self_types)]``#![feature(arbitrary_self_types)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
nagisa commentedon Oct 7, 2019
Seems like it is related entirely to the "arbitrary" self types thing.
poll_nextrequiresPin<_>as aself, andself.upstreamis notPin. We likely never encountered this beforePin, because with&and&mut, "receivers" were autoref'd.MCVE:
nagisa commentedon Oct 7, 2019
This also affects other stable "receivers" that are not subject to autoref, such as Rc or Arc.
cc #56805 @mikeyhew
Rantanen commentedon Oct 10, 2019
Another example
Playground
(Also note the formatting error in the text - rustc inserts the new bound after the current type, assuming that's where the colon is. Thus in this specific example the suggestion has invalid syntax due to the space before the colon in the code.)
fenhl commentedon Oct 25, 2019
Is there a way to work around this?
sfackler commentedon Oct 25, 2019
@fenhl see nagisa's comment above.
poll_nextmust be called onPin<&mut T>, notT.estebank commentedon Feb 17, 2020
Current output, we no longer provide the incorrect suggestions:
This is another case of #69069.
nagisa commentedon Feb 18, 2020
Should we close the duplicates? And also this issue, given that we no longer suggest wrong?
estebank commentedon Feb 18, 2020
Maybe, but let's make sure we link them up.
No, we need to improve the output when dealing with arbitrary self types. The current output is at least no longer wrong but it is misleading and actively confusing for anyone not intimately knowledgeable about the language.
Rollup merge of rust-lang#69255 - estebank:e0599-details, r=varkor
Rollup merge of rust-lang#69255 - estebank:e0599-details, r=varkor
Auto merge of #69255 - estebank:e0599-details, r=varkor
SkiFire13 commentedon Jun 6, 2020
@Rantanen your example gives me a different error.
This example instead:
gives the following error:
Playground
Also notice that this example isn't related to arbitrary self types but gives the same wrong suggestion.
estebank commentedon Sep 10, 2021
We now suggest an appropriate fix for the original report (although a few extra changes are needed to get to working code, the suggestions lead you all the way there):
We no longer suggest adding a bound when it was used in a const expression: