Skip to content
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

Async function return type inference fails without an ending return #64392

Closed
khionu opened this issue Sep 12, 2019 · 3 comments
Closed

Async function return type inference fails without an ending return #64392

khionu opened this issue Sep 12, 2019 · 3 comments
Labels
A-async-await Area: Async & Await A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@khionu
Copy link
Member

khionu commented Sep 12, 2019

I have a function of the signature async fn run() -> Result<!, Box<dyn std::error::Error>>. It ends with a loop that, as you may infer, never returns Ok. The inference for code generation failed, and the various compiler errors said that my function actually returned ().

@memoryruins
Copy link
Contributor

Can you provide a function/ playground that reproduces the errors?

@jonas-schievink jonas-schievink added A-async-await Area: Async & Await A-inference Area: Type inference AsyncAwait-Unclear C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 12, 2019
@khionu
Copy link
Member Author

khionu commented Sep 13, 2019

In trying to get a solid reproduction, the issue has disappeared from the codebase I discovered it in. 👻

@khionu khionu closed this as completed Sep 13, 2019
@aleksanb
Copy link

aleksanb commented Nov 9, 2019

I managed to reproduce this on stable (cargo 1.39.0 (1c6ec66d5 2019-09-30)), but it seems to be fixed on my current nightly (cargo 1.40.0-nightly (5da4b4d47 2019-10-28)). The failing code is:

async fn compile_fail_without_return() -> Result<i32, i32> {
    Result::<i32, i32>::Ok(20i32)?;
    //Result::<i32, i32>::Ok(20i32) If you add me, stable gives a sane message.
}

fn main() {}

This is the error on stable:

error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `std::ops::Try`)
  --> src/main.rs:27:5
   |
27 |     Result::<i32, i32>::Ok(20i32)?;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot use the `?` operator in a function that returns `()`
   |
   = help: the trait `std::ops::Try` is not implemented for `()`
   = note: required by `std::ops::Try::from_error`

error[E0271]: type mismatch resolving `<impl std::future::Future as std::future::Future>::Output == std::result::Result<i32, i32>`
  --> src/main.rs:26:43
   |
26 | async fn compile_fail_without_return() -> Result<i32, i32> {
   |                                           ^^^^^^^^^^^^^^^^ expected (), found enum `std::result::Result`
   |
   = note: expected type `()`
              found type `std::result::Result<i32, i32>`
   = note: the return type of a function must have a statically known size

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0271, E0277.
For more information about an error, try `rustc --explain E0271`.
error: could not compile `k`.

This is the error on nightly:

  --> src/main.rs:26:60
   |
26 |   async fn compile_fail_without_return() -> Result<i32, i32> {
   |  ____________________________________________________________^
27 | |     Result::<i32, i32>::Ok(20i32)?;
28 | |     //Result::<i32, i32>::Ok(20i32)
29 | | }
   | |_^ expected enum `std::result::Result`, found ()
   |
   = note: expected type `std::result::Result<i32, i32>`
              found type `()`

It seems like the function return type is clobbered somehow in the async transformation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants