Tracking issue for lazy type aliases

[GuillaumeGomez]

This is a tracking issue for the feature lazy type aliases.
It's considered to be a “sophisticated bug fix” for #21903, hence no RFC.
The feature gate for the issue is #![feature(lazy_type_alias)].

The feature implements the expected semantics for type aliases:

• Where-clauses and bounds on type parameters of type aliases are enforced.
• Type aliases are checked for well-formedness.
• Where-clauses are trailing instead of leading just like they are for associated types.
• Privacy: Private type aliases cannot be used in public signatures anymore,
  the type alias must also be made public (see also #114213).

It can only be stabilized as part of a new edition since the new semantics are incompatible with the status quo.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the feature (see Implementation history)
• Address any open issues and drive the feature to completeness
• Make the feature part of Rust 202X
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

None.

Resolved questions

• We currently don't imply any outlives-bounds on lazy type aliases to prevent introducing unsoundness which as it stands implied bounds would theoretically bring along. With this in mind, when is the best time to add implied bounds to lazy type aliases?
  • Zulip discussion.
  • T-lang consensus: This should be added before stabilization.
  • Further progress is tracked in #118479.
  • Implementation: #119350.

Implementation history

• Add AliasKind::Weak for type aliases. #108860
• Add lazy_type_alias feature gate #112853
• Permit recursive weak type aliases #113201
• Normalize lazy type aliases when probing for ADTs #113755
• Check lazy type aliases for well-formedness #114228
• Compute variances for lazy type aliases #114253
• Make the laziness of type aliases dependent on the defining crate #114566
• Structurally normalize weak and inherent in new solver #114594
• Unlock trailing where-clauses for lazy type aliases #114662
• Imply outlives-bounds on lazy type aliases #119350
• Improve the diagnostics for unused generic parameters #120556
• Properly deal with weak alias types as self types of impls #120780
• Expand weak alias types before collecting constrained/referenced late bound regions + refactorings #121344

Honorable Mentions

• Add TyAlias into rustc_type_ir TyKind enum #97974

---

Thanks to @fmease for writing this description. :)

[CAD97]

Recording:

Trailing where clauses on top level type aliases are currently syntax-stable (i.e. allowed under an inactive #[cfg]), and is only feature gated semantically (i.e. after macro expansion).

For other unstable features that were accidentally allowed as syntax-stable (e.g. macro items), we now have the forward-compatibility warning unstable_syntax_pre_expansion (#65860). We could potentially add this syntax into that machinery if we want to be conservative w.r.t. the unstable feature.

But on the other hand, trailing where is already allowed for associated types, so it being syntax stable for top level type aliases isn't particularly worrying or risky.

TL;DR: it being syntax stable deserves to be recorded, and is fine to remain such without any FCW (imo).