Explicitly don't normalize param-env in new solver#122403
Explicitly don't normalize param-env in new solver#122403compiler-errors wants to merge 2 commits intorust-lang:masterfrom
Conversation
lcnr
left a comment
There was a problem hiding this comment.
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