Treat weak alias types more like ADTs when computing implied bounds

[fmease]

For context, we want to treat lazy type aliases / weak alias types just like ADTs when computing implied bounds (#118479, T-lang design meeting 2023-11-09) but the way I've implemented it in #119350, there are some deviations in behavior which this PR eliminates.

I found this oversight while trying to build alloc with LTAs enabled by default: struct ExtractIfInner<'a, K, V> would no longer build requiring the explicit bounds K: 'a and V: 'a.

With this patch, we imply K: 'a, V: 'a instead of Root<K, V>: 'a in the following code which is consistent with ADTs:

#![feature(lazy_type_alias)]
struct ExtractIfInner<'a, K, V>(&'a mut Root<K, V>);
type Root<K, V> = (K, V);

Instead of treating weak alias types as abstract when computing the outlives-components like we do for the other kinds of alias types, we shallowly walk their generic args like we do with ADTs.

This is yet another case in a series (#121344, #120780) where weak alias types deviate in behavior from the other kinds of alias types, well... ^^'.

r? @oli-obk

[fmease]

Just a drive-by renaming, cc #117908. I don't know why this used the term free (ReLateParam). It should've always been named is_early_bound_region or sth. in that vein.

[fmease]

👀

[fmease]

WeakAlias<'co>: 'static now implies 'co: 'static similar to ADTs. Is that fine / sound?

[oli-obk]

it is, but we need tests that show that we actually enforce it, too. I don't know if we have any weak alias type tests for that, even if we have old-style type alias tests for it

[fmease]

👀

[fmease]

Similarly, WeakAlias<Co>: 'static now implies Co: 'static similar to ADTs. Is that acceptable?

[fmease]

I'm having second thoughts about this. Treating weak aliases like ADTs during infer_outlives, i.e., super-visiting them is meh (visiting its generic arguments), esp. for TAIT. Weak aliases aren't really nominal after all.

Let's take a look at ADTs: I can see why it's convenient to imply the bound T: 'a in struct Outer<'a, T>(&'a Inner<T>); (where struct Inner<T>(T);) even though this super-visiting approach is relatively "unrefined"/simple:

For example, for struct Outer<'a, T: Trait>(&'a T::P); (where trait Trait { type P; }) we "conservatively" infer &'a <T as Trait>::P (which is good!) instead of let's say T: 'a. However, once we hide the projection behind another ADT, we're back to the "component-wise" outlives inference.
Like, we imply the bound T: 'a in struct Outer<'a, T: Trait>(&'a Inner<T>) where struct Inner<T: Trait>(T::P); :)

So for weak aliases, this ADT-behavior would be even "worse". I don't think we want to imply the bound T: 'a in the following scenario:

#![feature(lazy_type_alias)]
type Ty<'a, T: Trait> = &'a Aux<T>;
type Aux<T: Trait> = T::P;
trait Trait { type P; }

On master, we imply the bound Aux<T>: 'a for Ty contrary to this branch which currently implies the bound T: 'a as it visits T inside &'a Aux<T>.

---

Yet again, I'm wondering if we should instead employ "type_of"/expand_weak_alias_tys here, even though I cringe at the thought already (well, regarding expand_weak_alias_tys that'd probably be problematic since it recursively drills through weak aliases without touching any potential predicates on the corresponding lazy type aliases, which seems pretty bad but I haven't spent much thought on that yet).

Ignoring the details for now, the "type_of approach" would allow us to keep imply the bound Opaque<T>: 'a in the following code I'm pretty sure:

type Opaque<T> = impl Sized;
fn define<T>() -> Opaque<T> {}
struct Ty<'a, T>(&'a Opaque<T>);

On this branch, we currently imply the bound T: 'a instead ... which is yuck?!

---

@oli-obk, thoughts? ^^'

[fmease]

In summary, the options might be:

1. Do nothing / keep as is. I.e., treat Alias(Weak) like any other Alias. This would mean we imply the bound Weak<T>: 'a when we're presented with e.g. <'a, T> &'a Weak<T>. As mentioned in the PR description, this would mean ExtractIfInner would no longer compile without modifications (i.e., adding more bounds).
2. Treat Alias(Weak) like ADTs (this PR). We would imply T: 'a when faced with <'a, T> &'a Weak<T>. "Issues" are explained in the comment above.
3. Peak inside the Alias(Weak) via ~type_of/expand_weak_alias_tys/... but we need to be careful (see comment above)! This more closely mimics the behavior of eager type aliases. We would only imply T: 'a in <'a, T> &'a Weak<T> if <T> Weak<T> "expands" (not normalizes) to a type that would imply T: 'a. We would continue to imply <T as Trait>::Projection: 'a if Weak "expands" to <T as Trait>::Projection and we would continue to imply Opaque<T>: 'a if Weak "expands" to Opaque<T>. This would also happen cross-crate, i.e., we would also expand type aliases from external crates. Seems fine?

[oli-obk]

can we somehow automatically encode this by wrapping weak alias types in a binder that has lifetimes for anything we could possibly want to bind? I guess this would be "precomputing" your option 3 and force every weak alias use site to think about what it wants.