-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Wrong obligation cause span of associated type mismatch #72806
Copy link
Copy link
Closed
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-bugCategory: This is a bug.Category: This is a bug.D-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-bugCategory: This is a bug.Category: This is a bug.D-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Bug
The following case (Playground) is slightly modifed based on that in #57663.
Error:
This is wrong. It points to
<Foo as Bar>::Ok, which is not related to the error.<Foo as Bar>::Okjust happens to have the same identifier as the mismatched associated typeBar2::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.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 currentimpl(impl Bar for Fooin this case) and looks for one having the same identifier as the projected item (Bar2::Okin this case). This is wrong and leads to the bug above. It just happens to work for the case in #57663, because in that caseBarrequirestype Sibling: Bar2<Ok=Self::Ok>and the two associated types have the same nameOk.PR #69793 refactors this code, adding a new branch (here) to look for
ProjectionPredicate::tyinstead (charin 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.