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

Misleading message for mismatch of associated type #58092

Closed
statiolake opened this issue Feb 3, 2019 · 2 comments · Fixed by #65977
Closed

Misleading message for mismatch of associated type #58092

statiolake opened this issue Feb 3, 2019 · 2 comments · Fixed by #65977
Labels
A-diagnostics Area: Messages for errors, warnings, and lints D-confusing Diagnostics: Confusing error or lint that should be reworked. D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@statiolake
Copy link

In the compiler message for type mismatching error of associated type, "expected A, found B" should be reversed ("expected B, found A").

struct X;

trait Foo {
    type Item;
}

impl Foo for X {
    type Item = i32;
}

fn foo(_: impl Foo<Item = f64>) {}

fn main() {
    foo(X);
}

The above example shows the error below:

error[E0271]: type mismatch resolving `<X as Foo>::Item == f64`
  --> (filename):14:5
   |
14 |     foo(X);
   |     ^^^ expected i32, found f64
   |
note: required by `foo`
  --> (filename):11:1
   |
11 | fn foo(_: impl Foo<Item = f64>) {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

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

Especially, compiler says "expected i32, found f64". However "expected f64, found i32" is more natural since the mismatching here is that the function foo() requires X::Item to be f64 but X::Item is actually i32.

Another example is below:

fn main() {
    let _ = vec![1, 2, 3].into_iter().cloned();
}

It causes an error like:

error[E0271]: type mismatch resolving `<std::vec::IntoIter<{integer}> as std::iter::Iterator>::Item == &_`
 --> (filename):2:39
  |
2 |     let _ = vec![1, 2, 3].into_iter().cloned();
  |                                       ^^^^^^ expected integer, found reference
  |
  = note: expected type `{integer}`
             found type `&_`

error: aborting due to previous error

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

The error here is that Iterator::cloned() requires Iterator::Item to be a reference but the supplied iterator here (vec![1, 2, 3].into_iter()) is a iterator generating integers. However error message is shown as if Iterator::cloned() required something to be an integer but that was reference. The message should be "expected reference, found integer".

Meta

rustc --version --verbose:

rustc 1.33.0-nightly (b43986184 2019-01-11)
binary: rustc
commit-hash: b43986184b8f4e0d633e8ae1704f0e19aec30cb2
commit-date: 2019-01-11
host: x86_64-pc-windows-msvc
release: 1.33.0-nightly
LLVM version: 8.0
@csmoe csmoe added the A-diagnostics Area: Messages for errors, warnings, and lints label Feb 3, 2019
@estebank
Copy link
Contributor

Current output for the first case:

error[E0271]: type mismatch resolving `<X as Foo>::Item == f64`
  --> src/main.rs:16:5
   |
13 | fn foo(_: impl Foo<Item = f64>) {}
   |    ---             ---------- required by this bound in `foo`
...
16 |     foo(X);
   |     ^^^ expected i32, found f64

No change in the second.

@estebank estebank added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 26, 2019
@estebank estebank added the D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. label Oct 18, 2019
@estebank
Copy link
Contributor

CC #57226

@estebank estebank added the D-confusing Diagnostics: Confusing error or lint that should be reworked. label Oct 18, 2019
tmandry added a commit to tmandry/rust that referenced this issue Oct 31, 2019
…-with-an-associated-type, r=estebank

Fix incorrect diagnostics for expected type in E0271 with an associated type

With code like the following code:

```rust
#[derive(Debug)]
struct Data {}

fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
    for item in iterator {
        println!("{:?}", item)
    }
}

fn main() {
    let v = vec![Data {}];

    do_stuff(v.into_iter());
}
```

the diagnostic (in nightly & stable) wrongly complains about the expected type:

```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
  --> src/main.rs:15:5
   |
5  | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
   |    --------                             --------------- required by this bound in `do_stuff`
...
15 |     do_stuff(v.into_iter());
   |     ^^^^^^^^ expected struct `Data`, found &Data
   |
   = note: expected type `Data`
              found type `&Data`
```

This PR fixes this issue by flipping the expected/actual values where appropriate, so it looks like this:

```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
  --> main.rs:15:5
   |
5  | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
   |    --------                             --------------- required by this bound in `do_stuff`
...
15 |     do_stuff(v.into_iter());
   |     ^^^^^^^^ expected &Data, found struct `Data`
   |
   = note: expected type `&Data`
              found type `Data`
```

This improves the output of a lot of existing tests (check out `associated-types-binding-to-type-defined-in-supertrait`!).

The only change which I wasn't too sure about is in the test `associated-types-overridden-binding-2`, but I think it's an improvement and the underlying problem is with handling of `trait_alias`.

Fix rust-lang#57226, fix rust-lang#64760, fix rust-lang#58092.
@bors bors closed this as completed in 959a563 Nov 1, 2019
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 D-confusing Diagnostics: Confusing error or lint that should be reworked. D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. 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