Repository navigation
Conversation
|
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 |
|
r? @adwinwhite rustbot has assigned @adwinwhite. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
63fd589 to
0870b5d
Compare
|
@rustbot reroll |
0870b5d to
18253f3
Compare
|
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. |
|
@bors r+ |
…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>
…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.
|
💔 I suspect this PR failed tests as part of a rollup After fixing the problem, consider running a try job for the failed job before re-approving. Link to failure: #165051 (comment) |
|
This pull request was unapproved. This PR was contained in a rollup (#165051), which was unapproved. |
18253f3 to
d1a9611
Compare
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 |
…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>
…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`)
Quoting from https://rustc-dev-guide.rust-lang.org/guides/editions.html#migration-lints:
However, as it stands we can't just stabilize feature
checked_type_aliasesin 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.,type_alias_boundsand 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)Sizedbounds would now be enforced at usage sites which could lead to local or downstream breakagesprivate_interfaceswhich might be set todenyor stricter leading to (soft) breakageTherefore, 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 featuremarked_unchecked_type_aliasesto be the aforementioned mechanism. Moreover, it introduces allow-by-default edition migration lintunmarked_unchecked_type_aliasesgated behind the same feature. The target edition in question is our dummyfuturewhich 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)