Skip to content

Unstably introduce MVP edition migration lint unmarked_unchecked_type_aliases together with bikeshed attribute #[rustc_unchecked_type_alias] - #164766

Open
fmease wants to merge 2 commits into
rust-lang:mainfrom
fmease:cta-migration-mvp
Open

fmease wants to merge 2 commits into
rust-lang:mainfrom
fmease:cta-migration-mvp

Conversation

@fmease

@fmease fmease commented Oct 22, 2026 •

Copy link
Copy Markdown
Member

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)

@fmease fmease added the F-checked_type_aliases `#![feature(checked_type_aliases)]` (formerly: `lazy_type_alias`) label Oct 22, 2026
@rustbot

rustbot commented Oct 22, 2026

Copy link
Copy Markdown
Collaborator

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 rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 22, 2026
@rustbot

rustbot commented Oct 22, 2026

Copy link
Copy Markdown
Collaborator

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

@fmease fmease moved this to In Progress in Checked Type Aliases (CTA) Oct 22, 2026
@rust-log-analyzer

This comment has been minimized.

@fmease
fmease force-pushed the cta-migration-mvp branch 2 times, most recently from 63fd589 to 0870b5d Compare October 22, 2026 22:39
@adwinwhite

Copy link
Copy Markdown
Contributor

@rustbot reroll

@rustbot rustbot assigned petrochenkov and unassigned adwinwhite Oct 23, 2026
@fmease
fmease force-pushed the cta-migration-mvp branch from 0870b5d to 18253f3 Compare October 23, 2026 19:58
@rustbot

rustbot commented Oct 23, 2026

Copy link
Copy Markdown
Collaborator

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.

@petrochenkov

Copy link
Copy Markdown
Contributor

@bors r+

@rust-bors

rust-bors Bot commented Oct 27, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 18253f3 has been approved by petrochenkov

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 27, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 27, 2026
…henkov

Unstably introduce MVP edition migration lint `unmarked_unchecked_type_aliases` together with bikeshed attribute `#[rustc_unchecked_type_alias]`

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 rust-lang#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 rust-lang#112792.

<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
rust-bors Bot pushed a commit that referenced this pull request Oct 27, 2026
…uwer

Rollup of 22 pull requests

Successful merges:

 - #159580 (Reject cfg on expressions that cannot be safely removed)
 - #162597 (raise ambiguity error on attribute macro that could be tool attribute)
 - #162808 (Enable `--generate-link-to-definition` rustdoc option on std docs)
 - #163059 (Recover invalid return type until `{`, `}` or `;`)
 - #163672 (Use runCodeGen Abstraction for new LLVM)
 - #164028 (Add a future incompat warning for #[no_link])
 - #164188 (Suggest adding lifetime for `dyn Trait` in return type)
 - #164345 (fix: handle `false` in root contexts)
 - #164494 (drop ands which are a superset of other ands)
 - #164766 (Unstably introduce MVP edition migration lint `unmarked_unchecked_type_aliases` together with bikeshed attribute `#[rustc_unchecked_type_alias]`)
 - #164785 (delegation: emit error when there is no field for `Self` mapping)
 - #164799 (Don't use `IntoIterator` in parallel API)
 - #164871 (Refactor call argument codegen)
 - #164648 (parse inline and rustc_force_inline with same parser)
 - #164811 (fix: Prevent ICE when comparing EII impl against generic declaration)
 - #164900 (make tool_attrs method to retrieve tool attributes.)
 - #164993 (copy_nonoverlapping: dont skip ovelrap check when src is fully uninit)
 - #164996 (miri: add missing alignment check in write_bytes)
 - #165012 (Remove Span::eq_ctxt())
 - #165013 ([tiny] Add missing backticks around lifetime name)
 - #165024 (rustdoc-search: rank re-export lower)
 - #165028 (Update enzyme to fix one bug related to higher-order derivatives)

> [!WARNING]
> This rollup conflicts with pending auto build #165042 and may need to be recreated if the pending build succeeds.
@JonathanBrouwer

Copy link
Copy Markdown
Member

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #165051 (comment)

@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 27, 2026
@rust-bors

rust-bors Bot commented Oct 27, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved.

This PR was contained in a rollup (#165051), which was unapproved.

View changes since this unapproval

@fmease
fmease force-pushed the cta-migration-mvp branch from 18253f3 to d1a9611 Compare October 28, 2026 16:21
@fmease

fmease commented Oct 28, 2026

Copy link
Copy Markdown
Member Author
diff --git a/compiler/rustc_lint/src/unmarked_unchecked_type_aliases.rs b/compiler/rustc_lint/src/unmarked_unchecked_type_aliases.rs
index 3d181b46eac..286e7f9316c 100644
--- a/compiler/rustc_lint/src/unmarked_unchecked_type_aliases.rs
+++ b/compiler/rustc_lint/src/unmarked_unchecked_type_aliases.rs
@@ -11,12 +11,14 @@
     ///
     /// ### Example
     ///
-    /// ```rust
+    #[cfg_attr(bootstrap, doc = "```rust,ignore")]
+    #[cfg_attr(not(bootstrap), doc = "```rust")]
     /// #![feature(marked_unchecked_type_aliases)]
     /// #![warn(unmarked_unchecked_type_aliases)]
     ///
     /// type Alias = [(); panic!()];
-    /// ```
+    #[cfg_attr(bootstrap, doc = "```")]
+    #[cfg_attr(not(bootstrap), doc = "```")]
     ///
     /// {{produces}}
     ///

@bors r=petrochenkov force

@rust-bors

rust-bors Bot commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

📌 Commit d1a9611 has been approved by petrochenkov

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 28, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Oct 28, 2026
…henkov

Unstably introduce MVP edition migration lint `unmarked_unchecked_type_aliases` together with bikeshed attribute `#[rustc_unchecked_type_alias]`

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 rust-lang#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 rust-lang#112792.

<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
rust-bors Bot pushed a commit that referenced this pull request Oct 28, 2026
…uwer

Rollup of 22 pull requests

Successful merges:

 - #165032 (stdarch subtree update)
 - #165072 (Submodule update of rustc-perf)
 - #144090 (Make `IoSlice` and `IoSliceMut` methods unstably const)
 - #162342 (More stdarch regression tests)
 - #163909 (std: Test the exit behavior of `abort` and `abort_immediate`)
 - #164766 (Unstably introduce MVP edition migration lint `unmarked_unchecked_type_aliases` together with bikeshed attribute `#[rustc_unchecked_type_alias]`)
 - #164916 (CI: rfl: move job forward to Linux v7.3)
 - #164924 (Remove `TypeKind` from `rustc_codegen_ssa`)
 - #164969 (perf: avoid allocating HashSet in is_distinct check on small SwitchInts)
 - #165083 (Gate `z` inline asm template modifier)
 - #165087 (Fix flaky CI test `named_temp_file_new_creates_file`)
 - #161131 (Check associated const binding types)
 - #161418 (give next-solver's `evaluate_const` its own `try_evaluate_const` logic)
 - #164315 (make powerpc `Complex` ABI GCC-compatible)
 - #164476 (Avoid ICE on None from prepare_vtable_segments)
 - #164981 (Reflection add TypeId::name)
 - #165003 (follow up for global-alloc-reentry test)
 - #165020 (Bless mir-opt panic-abort tests)
 - #165066 (skip max_repr_align in Layout::eq_abi)
 - #165080 (Syntactically allow C-variadics in parenthesized argument lists)
 - #165081 (move `#[rustc_allow_const_fn_unstable]` attr check to attr parsing stage)
 - #165082 (Remove stability note from `rust_splat`)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) F-checked_type_aliases `#![feature(checked_type_aliases)]` (formerly: `lazy_type_alias`) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

6 participants