Calling poll on an impl Future should suggest pinning.

[pnkfelix]

Code

use std::future::Future;
fn foo() -> impl Future<Output=()> {
    async { }
}

fn main() {
    let fut = foo();
    fut.poll()
}

Current output

error[E0599]: no method named `poll` found for opaque type `impl Future<Output = ()>` in the current scope
 --> src/main.rs:8:9
  |
8 |     fut.poll()
  |         ^^^^ method not found in `impl Future<Output = ()>`

For more information about this error, try `rustc --explain E0599`.

Desired output

error[E0599]: no method named `poll` found for opaque type `impl Future<Output = ()>` in the current scope
 --> src/main.rs:8:9
  |
8 |     fut.poll()
  |         ^^^^ method not found in `impl Future<Output = ()>`

For more information about this error, try `rustc --explain E0599`.

NOTE: Method `poll` found on `impl Future<Output = ()>` for `Pin<&mut Self>`. Please see documentation for `std::pin::Pin`.

Rationale and extra context

Someone who is just playing around based on the types and the rustdoc output is very likely to be confused by the current compiler error, because its easy to overlook the effect of Pin<&mut Self> as the receiver type for poll on std::future::Future. We can do a better job of gradually guiding the developer to the right solution, or at least push them towards the right solution space.

Other cases

No response

Anything else?

No response

[pnkfelix]

Pointing the user at std::pin::Pin struck me as the most natural solution given the signature (i.e. Pin<&mut Self>), but we could also provide a more tailored answer that points users at the async-book or some other resource entirely.

My guess, however, is that this is a general problem one might encounter with generalized Self in the receiver, and so we should thinking about how to tackle that general problem as well.

[Ezrashaw]

Is there a preferred message for .poll() on impl Future? Should we redirect them to async docs and/or tell them to pin it?

@rustbot claim

[Ezrashaw]

Note that the main part of this issue has been fixed. However, suggestions for generalized self parameters has not been fixed. I'll work on this at some point but if someone else wants to take it up then do so.

[Ezrashaw]

@pnkfelix Turns out that suggestions for this have always been around; this issue can be closed.