[fmease]

Quoting from https://rustc-dev-guide.rust-lang.org/guides/editions.html#migration-lints:

Migration lints are used to migrate projects from one edition to the next.
They are implemented with a MachineApplicable suggestion which
will rewrite code so that it will successfully compile in both the previous and the next
edition.

However, as it stands we can't just stabilize feature checked_type_aliases in the next edition because it would break the world (in the next edition); generally speaking, arbitrary implicitly unchecked type aliases (i.e., what we have today on stable) can't just become checked type aliases without breakage. E.g.,

• the RHS could be ill-formed (most likely diverging const exprs, dyn-incompatible trait refs or unmet projection bounds) in which case the alias could obviously never be migrated as is (this is not a theoretical point; see crater run in [crater] Also enforce dyn compatibility in (unchecked) type aliases #161358 for example).
• rather unlikely but the user could be ignoring lint type_alias_bounds and be writing explicit bounds which would now be enforced at usage sites which could lead to local or downstream breakages (i.e., a major change wrt. SemVer)
• more likely, implicit Sized bounds would now be enforced at usage sites which could lead to local or downstream breakages
• the type alias could be private & used in a public item signature which would now trigger lint private_interfaces which might be set to deny or stricter leading to (soft) breakage

Therefore, there must be a mechanism to define unchecked type aliases in the next edition / under feature checked_type_aliases. This mechanism could then be used by the edition migration lint for (unchecked) type aliases that cannot be turned into a checked one without breaking the local crate or downstream consumers thereof. Of course, the lint should try to avoid that mechanism where possible.

This PR introduces attribute #[rustc_unchecked_type_alias] (placeholder name) gated behind new unstable feature marked_unchecked_type_aliases to be the aforementioned mechanism. Moreover, it introduces allow-by-default edition migration lint unmarked_unchecked_type_aliases gated behind the same feature. The target edition in question is our dummy future which was added specifically for cases like this. Note that this PR only contains the MVP of the migration lint: Its impl won't try to figure out if adding #[rustc_unchecked_type_alias] would actually be necessary since that's most likely relatively involved & can be done iteratively.

Part of #112792.

_{(No LLM was or will be used by me during the entire creation process of this PR)}

[rustbot]

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[rustbot]

r? @adwinwhite

rustbot has assigned @adwinwhite.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 77 candidates
• Random selection from 20 candidates

[adwinwhite]

@rustbot reroll

[rustbot]

This PR was rebased onto a different main 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.