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

Slightly incorrect help message with mismatched typs in async code #66910

Closed
jfrimmel opened this issue Nov 30, 2019 · 4 comments · Fixed by #67009

Comments

@jfrimmel
Copy link

@jfrimmel jfrimmel commented Nov 30, 2019

The following works, since foo and bar return (), so the expression is simply returned:

fn foo() {}
fn bar() {
    foo()
}

The "equivalent" code in the async context yields a compiler error:

async fn foo() {}
async fn bar() {
    foo()
}
error[E0308]: mismatched types
  --> src/main.rs:62:5
   |
62 |     foo()
   |     ^^^^^- help: try adding a semicolon: `;`
   |     |
   |     expected (), found opaque type
   |
   = note: expected type `()`
              found type `impl core::future::future::Future`

The help message would be correct for non-async-code with mismatched types, but in the async case a .await should be suggested.

Technically the current help message is correct, but leads to another warning (that can be even overlooked):

warning: unused implementer of `core::future::future::Future` that must be used
  --> src/main.rs:62:5
   |
62 |     foo();
   |     ^^^^^^
   |
   = note: `#[warn(unused_must_use)]` on by default
   = note: futures do nothing unless you `.await` or poll them

So you have to do a second compile iteration.

I'd suggest to spawn a help message like that:

error[E0308]: mismatched types
  --> src/main.rs:62:5
   |
62 |     foo()
   |     ^^^^^- help: try to await the future: `.await`
   |     |
   |     expected (), found opaque type
   |
   = note: expected type `()`
              found type `impl core::future::future::Future`
@jfrimmel

This comment has been minimized.

Copy link
Author

@jfrimmel jfrimmel commented Nov 30, 2019

Note: this is the message with the current nightly (rustc 1.41.0-nightly (25d8a94 2019-11-29)).
Rust 1.39 does not even spawn the help message

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented Dec 3, 2019

Async await traige: marking as on-deck, as suggesting the use of .await seems pretty useful and general

@Aaron1011

This comment has been minimized.

Copy link
Contributor

@Aaron1011 Aaron1011 commented Dec 3, 2019

I started working on this, then realized that it already exists: #62067

However, it looks like we don't currently attempt to emit suggestions for certain coercions (including the return type coercion), which is why it doesn't show up here. I'm working on emitting coercion suggestions in more places.

@Aaron1011

This comment has been minimized.

Copy link
Contributor

@Aaron1011 Aaron1011 commented Dec 3, 2019

@rustbot claim

Centril added a commit to Centril/rust that referenced this issue Dec 6, 2019
…Centril

Emit coercion suggestions in more places

Fixes rust-lang#66910

We have several different kinds of suggestions we can try to make when
type coercion fails. However, we were previously only emitting these
suggestions from `demand_coerce_diag`. This resulted in the compiler
failing to emit applicable suggestions in several different cases, such
as when the implicit return value of a function had the wrong type.

This commit adds a new `emit_coerce_suggestions` method, which tries to
emit a number of related suggestions. This method is called from both
`demand_coerce_diag` and `CoerceMany::coerce_inner`, which covers a much
wider range of cases than before.

We now suggest using `.await` in more cases where it is applicable,
among other improvements.

I'm not happy about disabling the `issue-59756`, but from what I can tell, the suggestion infrastructure in rustc lacks any way of indicating mutually exclusive suggestions (and compiletest lacks a way to only apply a subset of available suggestions).
@bors bors closed this in 462f06d Dec 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.