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

Wrong obligation cause span of associated type mismatch #72806

Closed
xiaotianrandom opened this issue May 31, 2020 · 0 comments · Fixed by #72807
Closed

Wrong obligation cause span of associated type mismatch #72806

xiaotianrandom opened this issue May 31, 2020 · 0 comments · Fixed by #72807
Labels
A-associated-items Area: Associated items (types, constants & functions) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. 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

@xiaotianrandom
Copy link

Bug

The following case (Playground) is slightly modifed based on that in #57663.

trait Bar {
    type Ok;
    type Sibling: Bar2<Ok=char>; // Here is modified, not using Self::Ok anymore
}
trait Bar2 {
    type Ok;
}

struct Foo;
struct Foo2;

impl Bar for Foo {
    type Ok = ();
    type Sibling = Foo2;
}
impl Bar2 for Foo2 {
    type Ok = u32;
}

fn main() {}

Error:

error[E0271]: type mismatch resolving `<Foo2 as Bar2>::Ok == char`
  --> src/main.rs:13:15
   |
13 |     type Ok = ();
   |               ^^ expected `u32`, found `char`

This is wrong. It points to <Foo as Bar>::Ok, which is not related to the error. <Foo as Bar>::Ok just happens to have the same identifier as the mismatched associated type Bar2::Ok. If I change the identifier in this line to something else (Playground), the error changes to the following. It is still not clear, but at least not that wrong.

error[E0271]: type mismatch resolving `<Foo2 as Bar2>::Ok == char`
  --> src/main.rs:12:6
   |
12 | impl Bar for Foo {
   |      ^^^ expected `u32`, found `char`

Cause

This is introduced by the PR #65288. The PR tries to make compile errors of associated type mismatch more informative. For an obligation related to a ty::ProjectionPredicate, the PR (these lines) iterates over associated types in the current impl (impl Bar for Foo in this case) and looks for one having the same identifier as the projected item (Bar2::Ok in this case). This is wrong and leads to the bug above. It just happens to work for the case in #57663, because in that case Bar requires type Sibling: Bar2<Ok=Self::Ok> and the two associated types have the same name Ok.

PR #69793 refactors this code, adding a new branch (here) to look for ProjectionPredicate::ty instead (char in this case, not an associated type). This would work correctly for both this case and #57633. But this PR does not remove the old logic.

PR

I tried to delete the wrong branch and confirmed that all test cases passed as before. I will create a PR for that change shortly.

@xiaotianrandom xiaotianrandom added the C-bug Category: This is a bug. label May 31, 2020
@jonas-schievink jonas-schievink added A-associated-items Area: Associated items (types, constants & functions) 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 31, 2020
@estebank estebank added the D-incorrect Diagnostics: A diagnostic that is giving misleading or incorrect information. label May 31, 2020
@bors bors closed this as completed in 8e83a7e Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. 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