Properly deal with weak alias types as self types of impls

[fmease]

Fixes #114216.
Fixes #116100.

Not super happy about the two ad hoc “normalization” implementations for weak alias types:

1. In inherent_impls: The “peeling”, normalization to “WHNF”: Semantically that's exactly what we want (neither proper normalization nor shallow normalization would be correct here). Basically a weak alias type is “nominal” (well...^^) if the WHNF is nominal. #97974 followed the same approach.
2. In constrained_generic_params: Generic parameters are constrained by a weak alias type if the corresp. “normalized” type constrains them (where we only normalize weak alias types not arbitrary ones). Weak alias types are injective if the corresp. “normalized” type is injective.

Both have ad hoc overflow detection mechanisms.

Coherence is handled in #117164.

r? @oli-obk or types

[fmease]

Reminder to myself: Check if the following code leads to a cycle error:

#![feature(lazy_type_alias)]

struct I8<const F: i8>;

type Identity<T: ?Sized> = T;

impl Identity<I8<{ i8::MIN }>> {
    fn foo(&self) {}
}

Guillaume just sent me a document of them that records some issues encountered with the previous pre-ty::Weak approaches. Namely, the code above (ty::Weak → ty::Projection/#[lang = "identity"]) resulted in a cycle: https://hackmd.io/EI_RO0oKQ9OhssvpMrEDQA#Impl-block-on-a-projection

[fmease]

Update: No, it doesn't lead to cycles. Everything works flawlessly and let _ = I8::<-128>.foo(); is // check-pass.

[oli-obk]

Check if the following code leads to a cycle error:

yea, the previous approach used full normalization, which causes issues. Just peeling away the weak aliases works around all of that.

Sad that we need these custom normalization routines, but that's kinda the conclusion we always came to when we discussed these cases...

[fmease]

Added an ensure_sufficient_stack.

Sad that we need these custom normalization routines, but that's kinda the conclusion we always came to when we discussed these cases...

Yea :/ and I'm pretty sure we need to add more of them if we want to emulate some of the existing behavior of eager type aliases. E.g. for #114220 I bet we don't want to properly normalize either.

[oli-obk]

@bors r+

[bors]

📌 Commit 1a0323c has been approved by oli-obk

It is now in the queue for this repository.

[oli-obk]

These comments now need an @

[oli-obk]

@bors r-

ui tests now use //@ headers

[fmease]

🤦 👍

[fmease]

Let's wait till green to make sure I didn't mess up the new ui_test syntax and Imma bors approve on behalf of you later.

[fmease]

@bors r=oli-obk

[bors]

📌 Commit fde4556 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit fde4556 with merge 4993747...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[oli-obk]

@bors retry, empty log and possible apple-1 builder timeout

[fmease]

I think the retry didn't register
@bors retry

[bors]

⌛ Testing commit fde4556 with merge d3df8ff...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing d3df8ff to master...

[rust-timer]

Finished benchmarking commit (d3df8ff): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

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: 639.783s -> 642.411s (0.41%)
Artifact size: 308.82 MiB -> 308.84 MiB (0.00%)