Fix incorrect diagnostics for expected type in E0271 with an associated type by ohadravid · Pull Request #65977 · rust-lang/rust

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

With code like the following code:

#[derive(Debug)]structData{}fndo_stuff<'a>(iterator:implIterator<Item = &'aData>){for item in iterator {println!("{:?}", item)}}fnmain(){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 😄

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`. Fixrust-lang#57226, fixrust-lang#64760, fixrust-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`. Fixrust-lang#57226, fixrust-lang#64760, fixrust-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

Comment threadsrc/librustc/traits/error_reporting.rs Outdated

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 8bb5450Compare 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:masterNov 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

Navigation Menu

Uh oh!

Uh oh!

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
bors merged 1 commit into
rust-lang:masterfrom
ohadravid:fix-incorrect-diagnostics-with-an-associated-type

ohadravid commented Oct 30, 2019•
edited by estebank
Loading

Uh oh!

estebank commented Oct 30, 2019

Uh oh!

ohadravid commented Oct 30, 2019

Uh oh!

Uh oh!

estebank commented Oct 30, 2019

Uh oh!

bors commented Oct 30, 2019

Uh oh!

ohadravid commented Oct 31, 2019•
edited
Loading

Uh oh!

estebank commented Oct 31, 2019

Uh oh!

bors commented Oct 31, 2019

Uh oh!

gralpli commented Nov 2, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

ohadravid commented Oct 30, 2019• edited by estebank Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

estebank commented Oct 30, 2019

Uh oh!

ohadravid commented Oct 30, 2019

Uh oh!

Uh oh!

estebank commented Oct 30, 2019

Uh oh!

bors commented Oct 30, 2019

Uh oh!

ohadravid commented Oct 31, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

estebank commented Oct 31, 2019

Uh oh!

bors commented Oct 31, 2019

Uh oh!

gralpli commented Nov 2, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ohadravid commented Oct 30, 2019•
edited by estebank
Loading

ohadravid commented Oct 31, 2019•
edited
Loading