-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Normalize obligations before matching them against a candidate #109115
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we tend to assume that obligation
is already normalized. fulfill has an explicit normalization step, maybe we should also explicitly normalize at the start of evaluate instead? That should supersede both this PR and #103695
I guess we can leave this for the new trait solver. The issue is with the existing normalization during rust/compiler/rustc_trait_selection/src/traits/project.rs Lines 566 to 576 in 7c306f6
|
Doesn't this have the same problems as @BoxyUwU's attempt at deferred projection equality? particularly the type enum regression. |
I'm really not sure what the state of this is. r? @lcnr |
Closing this PR as it's a very lazy (as in, the work I did) approach to the problem that has unclear effects on other parts of trait solving. We'll wait for the new solver to land and then try again. |
Noticed again during #108860
When we are matching an impl against a predicate obligation, we normalize the impl predicate, but not the obligation predicate, causing errors like
trait bound for<'a> <Type as Trait>::Assoc<'a>: OtherTrait is not satisfied
, even though we have all the information available to figure out that the associated type is a type that implementsOtherTrait
.r? types
fixes #88460
fixes #90950
fixes #89196