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

[danielhenrymantilla]

Code

trait Trait { type Assoc; }

type AssocOf<T : ?Sized + Trait> = T::Assoc;

Current output

warning: bounds on generic parameters are not enforced in type aliases
 --> src/lib.rs:3:18
  |
3 | type AssocOf<T : ?Sized + Trait> = T::Assoc;
  |                  ^^^^^^   ^^^^^
  |
help: use fully disambiguated paths (i.e., `<T as Trait>::Assoc`) to refer to associated types in type aliases
 --> src/lib.rs:3:36
  |
3 | type AssocOf<T : ?Sized + Trait> = T::Assoc;
  |                                    ^^^^^^^^
  = note: `#[warn(type_alias_bounds)]` on by default
help: the bound will not be checked when the type alias is used, and should be removed
  |
3 - type AssocOf<T : ?Sized + Trait> = T::Assoc;
3 + type AssocOf<T > = T::Assoc;
  |

Desired output

No warning whatsoever

Rationale and extra context

Whilst it is true that left-hand-side bounds on generic parameters are not enforced in type aliases, { performing a Trait associated type "lookup" on / resolving the Trait associated type of } a given type T does effectively constrain T to be : ?Sized + Trait.

This means that for that specific snippet, the pattern is fine, both presently, and in the future, should these bounds end up enforced.

Whilst it may look like an oddly over-specific example, it is actually a common pattern to define a type alias as a shortcut for a trait associated type lookup.

Granted, the bounds could be skipped, like so:

- type AssocOf<T : ?Sized + Trait> = T::Assoc;
+ type AssocOf<T> = <T as Trait>::Assoc;

but this significantly hinders the quality of the generated documentation (now people need to look at the implementation/"value" of the type alias to try and figure out what the bounds on it are).

Other cases

Bonus points if when : Sized is a supertrait of T, the ?Sized + ends up not being required to prevent the lint from firing.

[fmease]

NB By the way, lazy_type_alias implements the desired semantics. See its tracking issue: #112792.

CC #21903.

[danielhenrymantilla]

Good to know there is progress on the "make type aliases work as expected" front 🙂.

But to avoid confusion, I do want to clarify that this is not what this issue is about, this one is a diagnostics issue, w.r.t. how type aliases currently work. That is, when using <T as Trait>::Assoc in the rhs of a type alias, this already, currently, enforces that T : ?Sized + Trait be true (and when Trait : Sized, we end up with T : Trait).
Given that, we should be allowed to add such bounds without having Rust warn us about our bounds being ignored, because given the rhs, they cannot be.

[fmease]

Right, that makes sense (I just had to do some advertising :P).

Yeah, the lint isn't super smart atm. This isn't the only case where bounds on type parameters of (eager) type aliases actually have a user-visible effect. Outlives-bounds for example may affect trait object lifetime defaults (we have an A-lint issue for that somewhere).

[danielhenrymantilla]

Thanks for improving my poor issue title 😄 @fmease 🙏

[danielhenrymantilla]

Should this have been "closed as completed"? The issue remains, we have a diagnostic firing unnecessarily:

Before #126575

warning: bounds on generic parameters are not enforced in type aliases
 --> src/lib.rs:3:18
  |
3 | type AssocOf<T : ?Sized + Trait> = T::Assoc;
  |                  ^^^^^^   ^^^^^
  |
help: use fully disambiguated paths (i.e., `<T as Trait>::Assoc`) to refer to associated types in type aliases
 --> src/lib.rs:3:36
  |
3 | type AssocOf<T : ?Sized + Trait> = T::Assoc;
  |                                    ^^^^^^^^
  = note: `#[warn(type_alias_bounds)]` on by default
help: the bound will not be checked when the type alias is used, and should be removed
  |
3 - type AssocOf<T : ?Sized + Trait> = T::Assoc;
3 + type AssocOf<T > = T::Assoc;
  |

After #126575

warning: bounds on generic parameters in type aliases are not enforced
 --> src/lib.rs:3:18
  |
3 | type AssocOf<T : ?Sized + Trait> = T::Assoc;
  |                  ^^^^^^   ^^^^^ will not be checked at usage sites of the type alias
  |
  = note: this is a known limitation of the type checker that may be lifted in a future edition.
          see issue #112792 <https://github.com/rust-lang/rust/issues/112792> for more information
  = help: add `#![feature(lazy_type_alias)]` to the crate attributes to enable the desired semantics
  = note: `#[warn(type_alias_bounds)]` on by default
help: remove this bound
  |
3 - type AssocOf<T : ?Sized + Trait> = T::Assoc;
3 + type AssocOf<T > = T::Assoc;
  |
help: fully qualify this associated type
  |
3 | type AssocOf<T : ?Sized + Trait> = <T as /* Trait */>::Assoc;
  |                                    +  +++++++++++++++

---

The PR in question mentions a wontfix:

• if so, the label ought to be added to this issue, which should be "grey-closed" rather than "closed as completed";
• I can understand it not being worth, currently, to make the lint smarter not to fire in these cases, but should such a situation warrant closing the issue altogether? I feel like by having this one closed, it's only a matter of time until a new similar issue arises 🤷

[fmease]

WONTFIX as per #126575. While my initial stance was to "true-fix" this issue, I spent two weeks thinking about it and I stand by my new view as laid out in my "manifesto" (#126575's PR description). I sympathize with anyone who might be annoyed by my decision. However, I think it's the best way forward. lazy_type_alias is the proper solution for this problem. CC #112792. I'm the current owner of this initiative and it's in my best interest to make type aliases more ergonomic and correct -- even if that means it takes more time.