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

ohadravid · 2019-10-30T18:39:02Z

With code like the following code:

#[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 #57226, fix #64760, fix #58092.

estebank · 2019-10-30T18:55:57Z

It looks good but I am also slightly concerned with associated-types-overridden-binding-2, but it is a weird construct where we don't point at trait I32Iterator = Iterator<Item = i32>; and it is a leveraging a nightly feature for it. I think the error was already not great, so r=me once CI is green.

ohadravid · 2019-10-30T21:01:50Z

@estebank CI is green 😄

src/librustc/traits/error_reporting.rs

estebank · 2019-10-30T23:39:08Z

@bors r+

bors · 2019-10-30T23:39:09Z

📌 Commit 7689aac618c61457d52b69b40c84fa7229c0e1d1 has been approved by estebank

…ed type

ohadravid · 2019-10-31T10:43:25Z

@estebank updated the code according to your comment, CI is green again

estebank · 2019-10-31T17:10:00Z

@bors r+ rollup

bors · 2019-10-31T17:10:01Z

📌 Commit 8bb5450 has been approved by estebank

…-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.

@ghost

Rollup of 14 pull requests Successful merges: - #65112 (Add lint and tests for unnecessary parens around types) - #65459 (Fix `-Zunpretty=mir-cfg` to render multiple items) - #65471 (Add long error explanation for E0578) - #65857 (rustdoc: Resolve module-level doc references more locally) - #65914 (Use structured suggestion for unnecessary bounds in type aliases) - #65945 (Optimize long-linker-command-line test) - #65946 (Make `promote_consts` emit the errors when required promotion fails) - #65960 (doc: reword iter module example and mention other methods) - #65963 (update submodules to rust-lang) - #65972 (Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets) - #65977 (Fix incorrect diagnostics for expected type in E0271 with an associated type) - #65995 (Add error code E0743 for "C-variadic has been used on a non-foreign function") - #65997 (Fix outdated rustdoc of Once::init_locking function) - #66005 (vxWorks: remove code related unix socket) Failed merges: r? @ghost

…-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.

@ghost

Rollup of 16 pull requests Successful merges: - #65112 (Add lint and tests for unnecessary parens around types) - #65470 (Don't hide ICEs from previous incremental compiles) - #65471 (Add long error explanation for E0578) - #65857 (rustdoc: Resolve module-level doc references more locally) - #65902 (Make ItemContext available for better diagnositcs) - #65914 (Use structured suggestion for unnecessary bounds in type aliases) - #65946 (Make `promote_consts` emit the errors when required promotion fails) - #65960 (doc: reword iter module example and mention other methods) - #65963 (update submodules to rust-lang) - #65972 (Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets) - #65977 (Fix incorrect diagnostics for expected type in E0271 with an associated type) - #65995 (Add error code E0743 for "C-variadic has been used on a non-foreign function") - #65997 (Fix outdated rustdoc of Once::init_locking function) - #66002 (Stabilize float_to_from_bytes feature) - #66005 (vxWorks: remove code related unix socket) - #66018 (Revert PR 64324: dylibs export generics again (for now)) Failed merges: r? @ghost

gralpli · 2019-11-02T07:35:36Z

Does this also fix #63211 ?

rust-highfive assigned estebank Oct 30, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 30, 2019

estebank reviewed Oct 30, 2019

View reviewed changes

src/librustc/traits/error_reporting.rs Outdated Show resolved Hide resolved

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 30, 2019

Fix incorrect diagnostics for expected type in E0271 with an associat…

8bb5450

…ed type

ohadravid force-pushed the fix-incorrect-diagnostics-with-an-associated-type branch from 7689aac to 8bb5450 Compare October 31, 2019 08:30

tmandry mentioned this pull request Oct 31, 2019

Rollup of 14 pull requests #66009

Closed

tmandry mentioned this pull request Nov 1, 2019

Rollup of 16 pull requests #66021

Merged

bors merged commit 8bb5450 into rust-lang:master Nov 1, 2019

ohadravid mentioned this pull request Nov 2, 2019

Associated types cause "expected" and "found" to be reversed in error messages #63211

Closed

ohadravid deleted the fix-incorrect-diagnostics-with-an-associated-type branch November 14, 2019 15:53

memoryruins mentioned this pull request Dec 17, 2019

Strange 'expected' and 'found' #67381

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

ohadravid commented Oct 30, 2019 •

edited by estebank

Loading

estebank commented Oct 30, 2019

ohadravid commented Oct 30, 2019

estebank commented Oct 30, 2019

bors commented Oct 30, 2019

ohadravid commented Oct 31, 2019 •

edited

Loading

estebank commented Oct 31, 2019

bors commented Oct 31, 2019

gralpli commented Nov 2, 2019

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

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

Conversation

ohadravid commented Oct 30, 2019 • edited by estebank Loading

estebank commented Oct 30, 2019

ohadravid commented Oct 30, 2019

estebank commented Oct 30, 2019

bors commented Oct 30, 2019

ohadravid commented Oct 31, 2019 • edited Loading

estebank commented Oct 31, 2019

bors commented Oct 31, 2019

gralpli commented Nov 2, 2019

ohadravid commented Oct 30, 2019 •

edited by estebank

Loading

ohadravid commented Oct 31, 2019 •

edited

Loading