-
Notifications
You must be signed in to change notification settings - Fork 14k
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
normalizeis a noop. This also skips theConstNormalizerhack innormalize_param_env_or_error, since we have deferred projection equality.r? @lcnr @BoxyUwU