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

Unhelpful error message for async method on invalid type #72590

Closed
euclio opened this issue May 25, 2020 · 0 comments · Fixed by #72621
Closed

Unhelpful error message for async method on invalid type #72590

euclio opened this issue May 25, 2020 · 0 comments · Fixed by #72621
Labels
A-async-await Area: Async & Await A-diagnostics Area: Messages for errors, warnings, and lints AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@euclio
Copy link
Contributor

euclio commented May 25, 2020

I tried this code:

Playground

struct Foo {
    foo: Nonexistent,
}

impl Foo {
    async fn frob(mut self) {}
}

I expected to see this happen: resolution error reported for Nonexistent type.

Instead, this happened: In addition to the resolution error, the compiler emitted errors complaining that it couldn't determine the size of Foo. That error is also emitted twice. These errors should be silent, since the true error is that Foo isn't fully formed.

error[E0412]: cannot find type `Nonexistent` in this scope
 --> src/lib.rs:2:10
  |
2 |     foo: Nonexistent,
  |          ^^^^^^^^^^^ not found in this scope

error[E0161]: cannot move a value of type Foo: the size of Foo cannot be statically determined
 --> src/lib.rs:6:19
  |
6 |     async fn frob(mut self) {}
  |                   ^^^^^^^^

error[E0161]: cannot move a value of type Foo: the size of Foo cannot be statically determined
 --> src/lib.rs:6:19
  |
6 |     async fn frob(mut self) {}
  |                   ^^^^^^^^

warning: variable does not need to be mutable
 --> src/lib.rs:6:19
  |
6 |     async fn frob(mut self) {}
  |                   ----^^^^
  |                   |
  |                   help: remove this `mut`
  |
  = note: `#[warn(unused_mut)]` on by default

error: aborting due to 3 previous errors; 1 warning emitted

Some errors have detailed explanations: E0161, E0412.
For more information about an error, try `rustc --explain E0161`.

Meta

rustc --version --verbose:

rustc 1.45.0-nightly (a74d1862d 2020-05-14)
binary: rustc
commit-hash: a74d1862d4d87a56244958416fd05976c58ca1a8
commit-date: 2020-05-14
host: x86_64-unknown-linux-gnu
release: 1.45.0-nightly
LLVM version: 9.0
Backtrace

<backtrace>

@euclio euclio added the C-bug Category: This is a bug. label May 25, 2020
@jonas-schievink jonas-schievink added A-async-await Area: Async & Await A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 25, 2020
@tmandry tmandry added D-confusing Diagnostics: Confusing error or lint that should be reworked. AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. labels May 26, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 27, 2020
…=nikomatsakis

Don't bail out of trait selection when predicate references an error

Fixes rust-lang#72590

With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is
going to fail. Therefore, there are no soundness impliciations to
continuing on when we encounter a `ty::Error` - we can only affect
whether or not additional error messags are emitted.

By not bailing out, we avoid incorrectly determining that types are
`!Sized` when a type error is present, which allows us to avoid emitting
additional spurious error messages.

The original comment mentioned this code being shared by coherence -
howver, this change resulted in no diagnostic changes in any of the
existing tests.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 27, 2020
…=nikomatsakis

Don't bail out of trait selection when predicate references an error

Fixes rust-lang#72590

With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is
going to fail. Therefore, there are no soundness impliciations to
continuing on when we encounter a `ty::Error` - we can only affect
whether or not additional error messags are emitted.

By not bailing out, we avoid incorrectly determining that types are
`!Sized` when a type error is present, which allows us to avoid emitting
additional spurious error messages.

The original comment mentioned this code being shared by coherence -
howver, this change resulted in no diagnostic changes in any of the
existing tests.
JohnTitor added a commit to JohnTitor/rust that referenced this issue May 30, 2020
…=nikomatsakis

Don't bail out of trait selection when predicate references an error

Fixes rust-lang#72590

With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is
going to fail. Therefore, there are no soundness impliciations to
continuing on when we encounter a `ty::Error` - we can only affect
whether or not additional error messags are emitted.

By not bailing out, we avoid incorrectly determining that types are
`!Sized` when a type error is present, which allows us to avoid emitting
additional spurious error messages.

The original comment mentioned this code being shared by coherence -
howver, this change resulted in no diagnostic changes in any of the
existing tests.
@bors bors closed this as completed in 1c30c9e May 30, 2020
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-diagnostics Area: Messages for errors, warnings, and lints AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants