-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Prefer param-env candidates that do no inference in new solver #109579
Prefer param-env candidates that do no inference in new solver #109579
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
201bfac
to
a22dd55
Compare
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.
would like to talk about this in sync as i have a slightly more involved refactoring to this part of the solver in mind here
☔ The latest upstream changes (presumably #109662) made this pull request unmergeable. Please resolve the merge conflicts. |
…rors prioritize param env candidates if they don't guide type inference intended to supersede rust-lang#109579. We disable the prioritization during coherence to maintain completeness. Long term we can hopefully replace this hack with adding OR to external constraints at which point the only relevant part when merging responses is whether they guide type inference in the same way. Reuses `try_merge_responses` for assembly and the cleanest way to impl that was to actually split that so that `try_merge_responses` returns `None` if we fail to merge them and then add `flounder` which is used afterwards which is allowed to lower the certainty of our responses. If, in the future, we add the ability to merge candidates `YES: ?0 = Vec<u32>` and `YES: ?0 = Vec<i32>` to `AMBIG: ?0 = Vec<?1>`, this should happen in `flounder`. r? `@compiler-errors` `@BoxyUwU`
r? @lcnr since we discussed that: