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

impl Trait error message expected/found order are confusing #68561

Closed
nikomatsakis opened this issue Jan 27, 2020 · 0 comments · Fixed by #80828
Closed

impl Trait error message expected/found order are confusing #68561

nikomatsakis opened this issue Jan 27, 2020 · 0 comments · Fixed by #80828
Labels
A-diagnostics A-impl-trait C-enhancement T-compiler

Comments

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 27, 2020

@jonas-schievink pointed out that the "expected/found" ordering for -> impl trait return types can be quite confusing:

trait Tr {
    type A;
}

impl<A> Tr for A {
    type A = A;
}

fn f() -> impl Tr<A=u8> {
    ()
}

gives

error[E0271]: type mismatch resolving `<() as Tr>::A == u8`
 --> src/lib.rs:9:11
  |
9 | fn f() -> impl Tr<A=u8> {
  |           ^^^^^^^^^^^^^ expected (), found u8
  |
  = note: expected type `()`
             found type `u8`
  = note: the return type of a function must have a statically known size

Additionally, the second note is wrong (() is Sized).

This does not happen when changing the code to use a boxed trait instead (expected and found are in the right order).

Originally posted by @jonas-schievink in #54326 (comment)

@nikomatsakis nikomatsakis added A-diagnostics A-impl-trait T-compiler labels Jan 27, 2020
@JohnTitor JohnTitor added the C-enhancement label Feb 2, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Apr 1, 2021
…ebank

Fix expected/found order on impl trait projection mismatch error

fixes rust-lang#68561

This PR adds a new `ObligationCauseCode` used when checking the concrete type of an impl trait satisfies its bounds, and checks for that cause code in the existing test to see if a projection's normalized type should be the "expected" or "found" type.

The second commit adds a `peel_derives` to that test, which appears to be necessary in some cases (see projection-mismatch-in-impl-where-clause.rs, which would still give expected/found in the wrong order otherwise). This caused some other changes in diagnostics not involving impl trait, but they look correct to me.
@bors bors closed this as completed in 4fa76a4 Apr 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics A-impl-trait C-enhancement T-compiler
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants