Tracking issue for lazy type aliases #112792

GuillaumeGomez · 2023-06-19T12:25:01Z

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)
- Amend style guide section for formatting where clauses in type aliases #114901
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

Honorable Mentions

Add TyAlias into rustc_type_ir TyKind enum #97974

Thanks to @fmease for writing this description. :)

The text was updated successfully, but these errors were encountered:

…oli-obk Add `lazy_type_alias` feature gate Add the `type_alias_type` to be able to have the weak alias used without restrictions. Part of rust-lang#112792. cc `@compiler-errors` r? `@oli-obk`

CAD97 · 2023-12-14T00:31:58Z

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).

…ds, r=compiler-errors Make it crystal clear what lint `type_alias_bounds` actually signifies This is part of my work on https://github.com/rust-lang/rust/labels/F-lazy_type_alias ([tracking issue](rust-lang#112792)). --- To recap, the lint `type_alias_bounds` detects bounds on generic parameters and where clauses on (eager) type aliases. These bounds should've never been allowed because they are currently neither enforced[^1] at usage sites of type aliases nor thoroughly checked for correctness at definition sites due to the way type aliases are represented in the compiler. Allowing them was an oversight. Explicitly label this as a known limitation of the type checker/system and establish the experimental feature `lazy_type_alias` as its eventual proper solution. Where this becomes a bit tricky (for me as a rustc dev) are the "secondary effects" of these bounds whose existence I sadly can't deny. As a matter of fact, type alias bounds do play some small roles during type checking. However, after a lot of thinking over the last two weeks I've come to the conclusion (not without second-guessing myself though) that these use cases should not trump the fact that these bounds are currently *inherently broken*. Therefore the lint `type_alias_bounds` should and will continue to flag bounds that may have subordinate uses. The two *known* secondary effects are: 1. They may enable the use of "shorthand" associated type paths `T::Assoc` (as opposed to fully qualified paths `<T as Trait>::Assoc`) where `T` is a type param bounded by some trait `Trait` which defines that assoc ty. 2. They may affect the default lifetime of trait object types passed as a type argument to the type alias. That concept is called (trait) object lifetime default. The second one is negligible, no question asked. The first one however is actually "kinda nice" (for writability) and comes up in practice from time to time. So why don't I just special-case trait bounds that "define" shorthand assoc type paths as originally planned in rust-lang#125709? 1. Starting to permit even a tiny subset of bounds would already be enough to send a signal to users that bounds in type aliases have been legitimized and that they can expect to see type alias bounds in the wild from now on (proliferation). This would be actively misleading and dangerous because those bounds don't behave at all like one would expect, they are *not real*[^2]! 1. Let's take `type A<T: Trait> = T::Proj;` for example. Everywhere else in the language `T: Trait` means `T: Trait + Sized`. For type aliases, that's not the case though: `T: Trait` and `T: Trait + ?Sized` for that matter do neither mean `T: Trait + Sized` nor `T: Trait + ?Sized` (for both!). Instead, whether `T` requires `Sized` or not entirely depends on the definition of `Trait`[^2]. Namely, whether or not it is bounded by `Sized`. 2. Given `type A<T: Trait<AssocA = ()>> = T::AssocB;`, while `X: Trait` gets checked given `A<X>` (by virtue of projection wfchecking post alias expansion[^2]), the associated type constraint `AssocA = ()` gets dropped entirely! While we could choose to warn on such cases, it would inevitably lead to a huge pile of special cases. 3. While it's common knowledge that the body / aliased type / RHS of an (eager) type alias does not get checked for well-formedness, I'm not sure if people would realize that that extends to bounds as well. Namely, `type A<T: Trait<[u8]>> = T::Proj;` compiles even if `Trait`'s generic parameter requires `Sized`. Of course, at usage sites `[u8]: Sized` would still end up getting checked[^2], so it's not a huge problem if you have full control over `A`. However, imagine that `A` was actually part of a public API and was never used inside the defining crate (not unreasonable). In such a scenario, downstream users would be presented with an impossible to use type alias! Remember, bounds may grow arbitrarily complex and nuanced in practice. 4. Even if we allowed trait bounds that "define" shorthand assoc type paths, we would still need to continue to warn in cases where the assoc ty comes from a supertrait despite the fact that the shorthand syntax can be used: `type A<T: Sub> = T::Assoc;` does compile given `trait Sub: Super {}` and `trait Super { type Assoc; }`. However, `A<X>` does not enforce `X: Sub`, only `X: Super`[^2]. All that to say, type alias bounds are simply not real and we shouldn't pretend they are! 5. Summarizing the points above, we would be legitimizing bounds that are completely broken! 2. It's infeasible to implement: Due to the lack of `TypeckResults` in `ItemCtxt` (and a way to propagate it to other parts of the compiler), the resolution of type-dependent paths in non-`Body` items (most notably type aliases) is not recoverable from the HIR alone which would be necessary because the information of whether an associated type path (projection) is a shorthand is only present pre&in-HIR and doesn't survive HIR ty lowering. Of course, I could rerun parts of HIR ty lowering inside the lint `type_alias_bounds` (namely, `probe_single_ty_param_bound_for_assoc_ty` which would need to be exposed or alternatively a stripped-down version of it). This likely has a performance impact and introduces complexity. In short, the "benefits" are not worth the costs. --- * 3rd commit: Update a diagnostic to avoid suggesting type alias bounds * 4th commit: Flag type alias bounds even if the RHS contains inherent associated types. * I started to allow them at some point in the past which was not correct (see commit for details) * 5th commit: Allow type alias bounds if the RHS contains const projections and GCEs are enabled * (and add a `FIXME(generic_const_exprs)` to be revisited before (M)GCE's stabilization) * As a matter of fact type alias bounds are enforced in this case because the contained AnonConsts do get checked for well-formedness and crucially they inherit the generics and predicates of their parent item (here: the type alias) * Remaining commits: Improve the lint `type_alias_bounds` itself --- Fixes rust-lang#125789 (sugg diag fix). Fixes rust-lang#125709 (wontfix, acknowledgement, sugg diag applic fix). Fixes rust-lang#104918 (sugg diag applic fix). Fixes rust-lang#100270 (wontfix, acknowledgement, sugg diag applic fix). Fixes rust-lang#94398 (true fix). r? `@compiler-errors` `@oli-obk` [^1]: From the perspective of the trait solver. [^2]: Given `type A<T: Trait> = T::Proj;`, the reason why the trait bound "`T: Trait`" gets *seemingly* enforced at usage sites of the type alias `A` is simply because `A<X>` gets expanded to "`<X as Trait>::Proj`" very early on and it's the *expansion* that gets checked for well-formedness, not the type alias reference.

Rollup merge of rust-lang#126575 - fmease:update-lint-type_alias_bounds, r=compiler-errors Make it crystal clear what lint `type_alias_bounds` actually signifies This is part of my work on https://github.com/rust-lang/rust/labels/F-lazy_type_alias ([tracking issue](rust-lang#112792)). --- To recap, the lint `type_alias_bounds` detects bounds on generic parameters and where clauses on (eager) type aliases. These bounds should've never been allowed because they are currently neither enforced[^1] at usage sites of type aliases nor thoroughly checked for correctness at definition sites due to the way type aliases are represented in the compiler. Allowing them was an oversight. Explicitly label this as a known limitation of the type checker/system and establish the experimental feature `lazy_type_alias` as its eventual proper solution. Where this becomes a bit tricky (for me as a rustc dev) are the "secondary effects" of these bounds whose existence I sadly can't deny. As a matter of fact, type alias bounds do play some small roles during type checking. However, after a lot of thinking over the last two weeks I've come to the conclusion (not without second-guessing myself though) that these use cases should not trump the fact that these bounds are currently *inherently broken*. Therefore the lint `type_alias_bounds` should and will continue to flag bounds that may have subordinate uses. The two *known* secondary effects are: 1. They may enable the use of "shorthand" associated type paths `T::Assoc` (as opposed to fully qualified paths `<T as Trait>::Assoc`) where `T` is a type param bounded by some trait `Trait` which defines that assoc ty. 2. They may affect the default lifetime of trait object types passed as a type argument to the type alias. That concept is called (trait) object lifetime default. The second one is negligible, no question asked. The first one however is actually "kinda nice" (for writability) and comes up in practice from time to time. So why don't I just special-case trait bounds that "define" shorthand assoc type paths as originally planned in rust-lang#125709? 1. Starting to permit even a tiny subset of bounds would already be enough to send a signal to users that bounds in type aliases have been legitimized and that they can expect to see type alias bounds in the wild from now on (proliferation). This would be actively misleading and dangerous because those bounds don't behave at all like one would expect, they are *not real*[^2]! 1. Let's take `type A<T: Trait> = T::Proj;` for example. Everywhere else in the language `T: Trait` means `T: Trait + Sized`. For type aliases, that's not the case though: `T: Trait` and `T: Trait + ?Sized` for that matter do neither mean `T: Trait + Sized` nor `T: Trait + ?Sized` (for both!). Instead, whether `T` requires `Sized` or not entirely depends on the definition of `Trait`[^2]. Namely, whether or not it is bounded by `Sized`. 2. Given `type A<T: Trait<AssocA = ()>> = T::AssocB;`, while `X: Trait` gets checked given `A<X>` (by virtue of projection wfchecking post alias expansion[^2]), the associated type constraint `AssocA = ()` gets dropped entirely! While we could choose to warn on such cases, it would inevitably lead to a huge pile of special cases. 3. While it's common knowledge that the body / aliased type / RHS of an (eager) type alias does not get checked for well-formedness, I'm not sure if people would realize that that extends to bounds as well. Namely, `type A<T: Trait<[u8]>> = T::Proj;` compiles even if `Trait`'s generic parameter requires `Sized`. Of course, at usage sites `[u8]: Sized` would still end up getting checked[^2], so it's not a huge problem if you have full control over `A`. However, imagine that `A` was actually part of a public API and was never used inside the defining crate (not unreasonable). In such a scenario, downstream users would be presented with an impossible to use type alias! Remember, bounds may grow arbitrarily complex and nuanced in practice. 4. Even if we allowed trait bounds that "define" shorthand assoc type paths, we would still need to continue to warn in cases where the assoc ty comes from a supertrait despite the fact that the shorthand syntax can be used: `type A<T: Sub> = T::Assoc;` does compile given `trait Sub: Super {}` and `trait Super { type Assoc; }`. However, `A<X>` does not enforce `X: Sub`, only `X: Super`[^2]. All that to say, type alias bounds are simply not real and we shouldn't pretend they are! 5. Summarizing the points above, we would be legitimizing bounds that are completely broken! 2. It's infeasible to implement: Due to the lack of `TypeckResults` in `ItemCtxt` (and a way to propagate it to other parts of the compiler), the resolution of type-dependent paths in non-`Body` items (most notably type aliases) is not recoverable from the HIR alone which would be necessary because the information of whether an associated type path (projection) is a shorthand is only present pre&in-HIR and doesn't survive HIR ty lowering. Of course, I could rerun parts of HIR ty lowering inside the lint `type_alias_bounds` (namely, `probe_single_ty_param_bound_for_assoc_ty` which would need to be exposed or alternatively a stripped-down version of it). This likely has a performance impact and introduces complexity. In short, the "benefits" are not worth the costs. --- * 3rd commit: Update a diagnostic to avoid suggesting type alias bounds * 4th commit: Flag type alias bounds even if the RHS contains inherent associated types. * I started to allow them at some point in the past which was not correct (see commit for details) * 5th commit: Allow type alias bounds if the RHS contains const projections and GCEs are enabled * (and add a `FIXME(generic_const_exprs)` to be revisited before (M)GCE's stabilization) * As a matter of fact type alias bounds are enforced in this case because the contained AnonConsts do get checked for well-formedness and crucially they inherit the generics and predicates of their parent item (here: the type alias) * Remaining commits: Improve the lint `type_alias_bounds` itself --- Fixes rust-lang#125789 (sugg diag fix). Fixes rust-lang#125709 (wontfix, acknowledgement, sugg diag applic fix). Fixes rust-lang#104918 (sugg diag applic fix). Fixes rust-lang#100270 (wontfix, acknowledgement, sugg diag applic fix). Fixes rust-lang#94398 (true fix). r? `@compiler-errors` `@oli-obk` [^1]: From the perspective of the trait solver. [^2]: Given `type A<T: Trait> = T::Proj;`, the reason why the trait bound "`T: Trait`" gets *seemingly* enforced at usage sites of the type alias `A` is simply because `A<X>` gets expanded to "`<X as Trait>::Proj`" very early on and it's the *expansion* that gets checked for well-formedness, not the type alias reference.

GuillaumeGomez added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Jun 19, 2023

GuillaumeGomez changed the title ~~Tracking Issue for type_alias_type feature flag~~ Tracking Issue for lazy_type_alias feature flag Jun 21, 2023

GuillaumeGomez mentioned this issue Jun 21, 2023

Add lazy_type_alias feature gate #112853

Merged

GuillaumeGomez mentioned this issue Jul 19, 2023

Functions using c_char show misleading "i8" instead of docs #113735

Open

rustbot added the F-lazy_type_alias `#![feature(lazy_type_alias)]` label Jul 29, 2023

fmease mentioned this issue Jul 29, 2023

Rust 2024 survey rust-lang/lang-team#209

Closed

crlf0710 added the A-maybe-future-edition Something we may consider for a future edition. label Jul 30, 2023

Centri3 mentioned this issue Aug 2, 2023

Lossy type aliases in cast_lossless lint rust-lang/rust-clippy#11285

Closed

GuillaumeGomez mentioned this issue Aug 10, 2023

Add missing normalization when checking const generics #114702

Closed

fmease mentioned this issue Aug 25, 2023

Trait bounds are not yet enforced in type definitions #21903

Open

This comment was marked as resolved.

Sign in to view

fmease mentioned this issue Sep 23, 2023

lazy type alias: type parameters are not considered constrained in impls #116100

Closed

This comment was marked as resolved.

Sign in to view

This was referenced Oct 5, 2023

Add TyAlias into rustc_type_ir TyKind enum #97974

Closed

finish up type alias PRs #55222

Closed

nikomatsakis mentioned this issue Oct 11, 2023

Enforce where-clauses on type aliases via alias type rust-lang/types-team#111

Open

tmandry added this to Lang Edition 2024 Nov 3, 2023

tmandry moved this to Idea in Lang Edition 2024 Nov 3, 2023

dtolnay mentioned this issue Nov 5, 2023

Parse lazy type alias syntax dtolnay/syn#1525

Open

fmease self-assigned this Dec 28, 2023

fmease added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Dec 28, 2023

tmandry moved this from Idea to Design in Lang Edition 2024 Jan 10, 2024

tmandry moved this from Design to Implementation in Lang Edition 2024 Jan 10, 2024

fmease mentioned this issue Jan 10, 2024

Reject bounds in type aliases with edition 2024 #49441

Open

fmease changed the title ~~Tracking Issue for lazy_type_alias feature flag~~ Tracking issue for lazy type aliases Jan 23, 2024

This was referenced Jan 23, 2024

Suggest unused lifetime parameters #119236

Open

Outlives-bounds in type aliases may affect object lifetime defaults which lint type_alias_bounds fails to acknowledge #100270

Closed

This comment was marked as resolved.

Sign in to view

fmease added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Feb 21, 2024

github-actions bot mentioned this issue Apr 9, 2024

rust/1.77.2 package update wolfi-dev/os#16567

Merged

fmease mentioned this issue May 29, 2024

Lint type_alias_bounds fires unnecessarily for trait bounds that define short-hand projections on the RHS #125709

Closed

johannesherschel mentioned this issue May 30, 2024

Misleading suggestion to add bound to type alias parameter #125789

Closed

fmease added S-tracking-impl-incomplete Status: The implementation is incomplete. S-tracking-needs-migration-lint Status: This item needs a migration lint. labels Sep 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for lazy type aliases #112792

Tracking issue for lazy type aliases #112792

GuillaumeGomez commented Jun 19, 2023 •

edited by fmease

Loading

This comment was marked as resolved.

This comment was marked as resolved.

CAD97 commented Dec 14, 2023

This comment was marked as resolved.

This comment was marked as resolved.

Tracking issue for lazy type aliases #112792

Tracking issue for lazy type aliases #112792

Comments

GuillaumeGomez commented Jun 19, 2023 • edited by fmease Loading

About tracking issues

Steps

Unresolved questions

Resolved questions

Implementation history

Honorable Mentions

This comment was marked as resolved.

This comment was marked as resolved.

CAD97 commented Dec 14, 2023

This comment was marked as resolved.

This comment was marked as resolved.

GuillaumeGomez commented Jun 19, 2023 •

edited by fmease

Loading