-
Notifications
You must be signed in to change notification settings - Fork 14k
Show env normalization differences under two solvers #148939
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
base: main
Are you sure you want to change the base?
Conversation
|
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
This comment has been minimized.
This comment has been minimized.
5cd4303 to
4408f14
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| // FIXME: `generic_const_exprs` causes query cycle problem. Same as the old solver. | ||
| if !ct.has_aliases() || infcx.tcx.features().generic_const_exprs() { |
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.
hmm, disable the lint if generic_const_exprs is enabled instead
First step for param_env normalization future compat warning. zulip thread
I didn't put the check directly in
param_envquery becausenormalize_param_env_or_errorhas some adjustments on the predicates: elaboration and outlive predicates manipulation. I'd have to replicate these inparam_envto compare normalized predicates properly.The downside of putting the check inside
normalize_param_env_or_erroris that it's used in more thanparam_envquery. It's also used incompare_impl_itemand several other places. I'm not sure if this is desired.I didn't bless tests since the hard error will be changed to lint later.Blessed tests to demonstrate the changes.
And there's one test about const generics I don't know how to fix.
Canonicalizer for the next solver will replace
ParamConstwithPlaceholderConst, but it still uses the sametry_evaluate_constinternally andprocess_obligationdoesn't likePlaceholderConst.r? @lcnr