Skip to content

Strange unreachable warning in Future #60394

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sbwtw opened this issue Apr 30, 2019 · 2 comments · Fixed by #64592
Closed

Strange unreachable warning in Future #60394

sbwtw opened this issue Apr 30, 2019 · 2 comments · Fixed by #64592
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@sbwtw
Copy link
Contributor

sbwtw commented Apr 30, 2019

Code:

use futures::future;
use futures::Future;

fn f() -> impl Future<Item = (), Error = ()> {
    future::ok(unimplemented!())
}

fn main() {
    let s = f();

    tokio::run(s);
}

And when build with cargo build, It will says the future::ok(unimplemented!()) is unreachable expression.
but when cargo run, I got a panic: thread 'main' panicked at 'not yet implemented', src\main.rs:5:16. the unimplemented!() macro is worked.

@Centril Centril added the A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. label Apr 30, 2019
@Centril
Copy link
Contributor

Centril commented Apr 30, 2019

What happens here is that the function call future::ok(...) is unreachable. The macro "call" itself isn't.
We can see this with:

use futures::{future, Future};

fn f() -> impl Future<Item = (), Error = ()> {
    let _u = unimplemented!();
    future::ok(_u)
}

fn main() {
    tokio::run(f());
}

cc @estebank Can we highlight the issue like so perhaps?

warning: unreachable expression
 --> src/main.rs:4:5
  |
4 |     future::ok(unimplemented!())
  |     ^^^^^^^^^^^----------------^

@Centril Centril added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 30, 2019
@estebank
Copy link
Contributor

I think this will be a side effect of a long standing paper cut, where we point at the method or entire statement instead of the argument that caused a problem. I can take a look, but I don't think this will be fixed in the near term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
3 participants