Retire ast::TyAliasWhereClauses.

[cjgillot]

ast::TyAliasWhereClauses is a tentative to avoid forgetting predicates when manipulating the AST.
It is incompatible with cfg attributes on where clauses.

This PR uses a regular WhereClause for the "second" clause.

Fixes #138010
cc #138037

[fmease]

Could you use the more minimal reproducers, #138010 (comment) and/or #138010 (comment) which are less obfuscated. Moreover, #138010 (comment) wouldn't require any extra unstable features.

[fmease]

With my comment above I meant removing any of the redundant and distracting bits of cfg-attr-issue-138010-1.rs given it's a fuzzer-produced file (extra functions, check-cfg warnings, a useless let binding, useless (): bounds, etc.).

It can be distilled to:

#![feature(lazy_type_alias)]
#![expect(incomplete_features)]

type Type
where
    #[cfg(false)]
    String: Copy,
= ();

fn main() {}

… which just shows that it's just cfg-attr-issue-138010-2.rs.

So could you please throw out the *-1.rs or replace *-1.rs with the MCVE above and remove the *-2.rs (I don't really care about the #[cfg(true)] case but whatever).

[jackh726]

IIRC adding the purpose of adding this type was never to avoid allocating vecs, but rather to maintain the two separate Span locations and the predicates derived for them, and also unify the handling of the where clauses (with the idea that we may remove the ability to remove the before where clauses at some point, I also don't remember if there was some specific motivating reason for this or if it was just a general decision).

I'm a little surprised we don't regress any test outputs, but I guess all the info is still there, but now less well-defined.

I have mixed feelings here. I worry that this could lead to places checking the where clauses in generics but not in after_where_clauses, that was perhaps the motivating reason for this. Them being in the same place means that nobody can forget about them anywhere.

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[cjgillot]

IIRC adding the purpose of adding this type was never to avoid allocating vecs, but rather to maintain the two separate Span locations and the predicates derived for them, and also unify the handling of the where clauses (with the idea that we may remove the ability to remove the before where clauses at some point, I also don't remember if there was some specific motivating reason for this or if it was just a general decision).

I'm a little surprised we don't regress any test outputs, but I guess all the info is still there, but now less well-defined.

I'm not sure about the "less well-defined". In the current state, we have the information about the "before" span twice. Here we have everything once.

I have mixed feelings here. I worry that this could lead to places checking the where clauses in generics but not in after_where_clauses, that was perhaps the motivating reason for this. Them being in the same place means that nobody can forget about them anywhere.

This is mitigated by lowering. Most of the places where we manipulate predicates are on HIR, which does merge the lists. On the other hand, AST needs to be as close to the concrete syntax as possible for macro expansion.

[jackh726]

IIRC adding the purpose of adding this type was never to avoid allocating vecs, but rather to maintain the two separate Span locations and the predicates derived for them, and also unify the handling of the where clauses (with the idea that we may remove the ability to remove the before where clauses at some point, I also don't remember if there was some specific motivating reason for this or if it was just a general decision).
I'm a little surprised we don't regress any test outputs, but I guess all the info is still there, but now less well-defined.

I'm not sure about the "less well-defined". In the current state, we have the information about the "before" span twice. Here we have everything once.

Yes, "less well-defined" is perhaps not the right way to say this. What I mostly trying to say is that I could have imagined that it would have been easy (and could be easy in the future) to miss a case where we need to do something with both the where clauses in generics and after_where_clauses (whereas prior to this PR, it's not an "extra" thing you have to think about)

I have mixed feelings here. I worry that this could lead to places checking the where clauses in generics but not in after_where_clauses, that was perhaps the motivating reason for this. Them being in the same place means that nobody can forget about them anywhere.

This is mitigated by lowering. Most of the places where we manipulate predicates are on HIR, which does merge the lists. On the other hand, AST needs to be as close to the concrete syntax as possible for macro expansion.

Okay, good enough for me, I guess.

[fmease]

With my comment above I meant removing any of the redundant and distracting bits of cfg-attr-issue-138010-1.rs given it's a fuzzer-produced file (extra functions, check-cfg warnings, a useless let binding, useless (): bounds, etc.).

It can be distilled to:

#![feature(lazy_type_alias)]
#![expect(incomplete_features)]

type Type
where
    #[cfg(false)]
    String: Copy,
= ();

fn main() {}

… which just shows that it's just cfg-attr-issue-138010-2.rs.

So could you please throw out the *-1.rs or replace *-1.rs with the MCVE above and remove the *-2.rs (I don't really care about the #[cfg(true)] case but whatever).

[fmease]

Thanks! Some final nits (+ optional squash), then r=me

@bors rollup

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[cjgillot]

@bors r=fmease

[bors]

📌 Commit 15c91bf has been approved by fmease

It is now in the queue for this repository.