move super_relate_consts hack to normalize_param_env_or_error

[BoxyUwU]

super_relate_consts has as hack in it to work around the fact that normalize_param_env_or_error is broken. When relating two constants we attempt to evaluate them (aka normalize them). This is not an issue in any way specific to const generics, type aliases also have the same issue as demonstrated in this code.

Since the hack in super_relate_consts only exists to make normalize_param_env_or_error emit less errors move it to normalize_param_env_or_error. This makes super_relate_consts act more like the normal plain structural equality its supposed to and should help ensure that the hack doesnt accidentally affect other situations.

r? @compiler-errors

[compiler-errors]

@bors try

[bors]

⌛ Trying commit 2badab9fab1aa42e42da93c8867b6dd3b939db43 with merge 5544613b027fde133f28359e75dec57e222e7ee4...

[compiler-errors]

@rust-timer queue

[bors]

☀️ Try build successful - checks-actions
Build commit: 5544613b027fde133f28359e75dec57e222e7ee4 (5544613b027fde133f28359e75dec57e222e7ee4)

[compiler-errors]

@craterbot check

[craterbot]

👌 Experiment pr-111623 created and queued.
🤖 Automatically detected try build 5544613b027fde133f28359e75dec57e222e7ee4
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[rust-timer]

Finished benchmarking commit (5544613b027fde133f28359e75dec57e222e7ee4): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.9%	[1.9%, 1.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.5%	[-1.5%, -1.4%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 644.092s -> 644.08s (-0.00%)

[craterbot]

🚧 Experiment pr-111623 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-111623 is completed!
📊 4 regressed and 1 fixed (275257 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[BoxyUwU]

Interestingly I thought this PR was a breaking change and would need a t-types FCP because you could hide a const arg behind an alias so this syntactic "evaluate anon consts" folder would miss it, but actually I think that's not possible because type aliases are broken in normalize_param_env_or_error and aren't normalized. I was thinking a repro like:

trait Trait<T> {
    type Assoc;
}

trait Other {
    type Bar;
}

impl<T> Other for T {
    type Bar = [T; 1 + 2];
}

fn foo<T, U>() 
where
    <U as Trait<[T; 1 + 2]>>::Assoc: Sized,
    U: Trait<<T as Other>::Bar>,
{

}

but this doesn't compile on stable so it's fine for it to not compile. I think this should be fine to land. No idea why the new solver test is failing though 🙃

[BoxyUwU]

attemtping to prove [Foo; 1]: Default breaks under the new solver with this PR because the impl in std is [Foo; AnonConst]: Default which we equate with [Foo; 1]: Default. New solver does not normalize constants so AnonConst does not unify with 1 even though evaluating the anon const would result in 1. This test was accidentally relying on the super_relate_consts hack which is a great example of why we need this PR lol

This PR is fine to land even with this, new solver is completely experimental and needs to have const normalization implemented at some point anyway.

[compiler-errors]

r=me nit preferably

[BoxyUwU]

@bors rollup=never (i want this to be easy to bisect to if it causes regressions)

[BoxyUwU]

@bors r=compiler-errors

[bors]

📌 Commit 21cf9ea has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit 21cf9ea with merge e29821f...

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing e29821f to master...

[rust-timer]

Finished benchmarking commit (e29821f): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.2%, 0.6%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.2%]	2
Improvements ✅ (secondary)	-2.0%	[-2.2%, -2.0%]	6
All ❌✅ (primary)	0.2%	[-0.3%, 0.6%]	10

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 642.897s -> 643.422s (0.08%)