-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Explicitly don't normalize param-env in new solver #122403
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
Explicitly don't normalize param-env in new solver #122403
Conversation
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.
It feels a bit dangerous that we always have to explicitly elaborate when creating a new ParamEnv
. I would like to have a slightly less "boring" name for fn new
but can't think of anything too useful. Maybe ParamEnv::from_raw_components
or something like that 🤔
r=me no matter what you prefer here
I think |
1c2154b
to
eacc881
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
The job Click to see the possible cause of the failure (guessed by this bot)
|
for rust-lang/trait-system-refactor-initiative#90 we might wind up with another step that we do in param env construction which under this PR would be another thing every callsite of Seeing as how |
I agree with boxy and think that we may want to add additional assumptions about the input when creating a |
☔ The latest upstream changes (presumably #123058) made this pull request unmergeable. Please resolve the merge conflicts. |
Make it clear that we don't normalize param-envs in the new solver, since
normalize
is a noop. This also skips theConstNormalizer
hack innormalize_param_env_or_error
, since we have deferred projection equality.r? @lcnr @BoxyUwU