Handle rustc_const_stable attribute in library feature collector #95354

dtolnay · 2022-03-27T04:11:50Z

The library feature collector in compiler/rustc_passes/src/lib_features.rs has only been looking at #[stable(…)], #[unstable(…)], and #[rustc_const_unstable(…)] attributes, while ignoring #[rustc_const_stable(…)]. The consequences of this were:

When any const feature got stabilized (changing one or more rustc_const_unstable to rustc_const_stable), users who had previously enabled that unstable feature using #![feature(…)] would get told "unknown feature", rather than rustc's nicer "the feature … has been stable since … and no longer requires an attribute to enable".

This can be seen in the way that Stabilize const_ptr_offset #93957 (comment) failed after rebase:
```
error[E0635]: unknown feature `const_ptr_offset`
  --> $DIR/offset_from_ub.rs:1:35
   |
LL | #![feature(const_ptr_offset_from, const_ptr_offset)]
   |                                   ^^^^^^^^^^^^^^^^
```
We weren't enforcing that a particular feature is either stable everywhere or unstable everywhere, and that a feature that has been stabilized has the same stabilization version everywhere, both of which we enforce for the other stability attributes.

This PR updates the library feature collector to handle rustc_const_stable, and fixes places in the standard library and test suite where rustc_const_stable was being used in a way that does not meet the rules for a stability attribute.

rust-highfive · 2022-03-27T04:11:54Z

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

oli-obk · 2022-03-30T11:21:17Z

cc @jhpratt you've been working on related changes

m-ou-se · 2022-03-30T11:29:45Z

r? rust-lang/compiler

jhpratt · 2022-03-30T14:38:18Z

While I'm not on the list of reviewers, I'll still take a look later today.

jhpratt

Change the the compiler looks good as-is. There's two places where I do have questions, though.

jhpratt · 2022-03-31T03:55:39Z

src/test/ui/consts/const-eval/simd/insert_extract.rs

@@ -2,7 +2,7 @@
 #![feature(repr_simd)]
 #![feature(platform_intrinsics)]
 #![feature(staged_api)]
-#![stable(feature = "foo", since = "1.33.7")]
+#![stable(feature = "foo", since = "1.3.37")]


Any particular reason for this change?

error[E0711]: feature `foo` is declared stable since 1.3.37, but was previously declared stable since 1.33.7 --> /git/rust/src/test/ui/consts/const-eval/simd/insert_extract.rs:15:5 | LL | #[rustc_const_stable(feature = "foo", since = "1.3.37")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0711]: feature `foo` is declared stable since 1.3.37, but was previously declared stable since 1.33.7 --> /git/rust/src/test/ui/consts/const-eval/simd/insert_extract.rs:17:5 | LL | #[rustc_const_stable(feature = "foo", since = "1.3.37")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors

Ah, didn't look at the full context.

jhpratt · 2022-03-31T03:56:50Z

library/core/src/mem/maybe_uninit.rs

@@ -905,7 +905,7 @@ impl<T> MaybeUninit<T> {
    /// };
    /// ```
    #[stable(feature = "maybe_uninit_ref", since = "1.55.0")]
-    #[rustc_const_unstable(feature = "const_maybe_uninit_assume_init", issue = "none")]
+    #[rustc_const_unstable(feature = "const_maybe_uninit_assume_init_mut", issue = "none")]


The two changes in this file are the only ones where an unstable feature gate is being changed. Is there a reason this is the case, as opposed to changing the gate for the already-stabilized part of this feature?

No reason. I didn't put a lot of thought into the required name changes but I would be happy to consider suggestions.

I think it would make more sense to change the gate that's already stabilized, as that would avoid unnecessary breakage on Rust's end.

Fixed in 9479358dda11c677064b89d676a8b67d0181be3b

dtolnay · 2022-03-31T19:54:32Z

Rebased to fix feature naming problems introduced by Strict Provenance MVP #95241

lcnr · 2022-04-01T07:22:57Z

thanks @jhpratt for your review

@bors r+ rollup

bors · 2022-04-01T07:22:58Z

📌 Commit 971ecff has been approved by lcnr

Handle rustc_const_stable attribute in library feature collector The library feature collector in [compiler/rustc_passes/src/lib_features.rs](https://github.com/rust-lang/rust/blob/551b4fa395fa588d91cbecfb0cdfe1baa02670cf/compiler/rustc_passes/src/lib_features.rs) has only been looking at `#[stable(…)]`, `#[unstable(…)]`, and `#[rustc_const_unstable(…)]` attributes, while ignoring `#[rustc_const_stable(…)]`. The consequences of this were: - When any const feature got stabilized (changing one or more `rustc_const_unstable` to `rustc_const_stable`), users who had previously enabled that unstable feature using `#![feature(…)]` would get told "unknown feature", rather than rustc's nicer "the feature … has been stable since … and no longer requires an attribute to enable". This can be seen in the way that rust-lang#93957 (comment) failed after rebase: ```console error[E0635]: unknown feature `const_ptr_offset` --> $DIR/offset_from_ub.rs:1:35 | LL | #![feature(const_ptr_offset_from, const_ptr_offset)] | ^^^^^^^^^^^^^^^^ ``` - We weren't enforcing that a particular feature is either stable everywhere or unstable everywhere, and that a feature that has been stabilized has the same stabilization version everywhere, both of which we enforce for the other stability attributes. This PR updates the library feature collector to handle `rustc_const_stable`, and fixes places in the standard library and test suite where `rustc_const_stable` was being used in a way that does not meet the rules for a stability attribute.

Rollup of 8 pull requests Successful merges: - rust-lang#95354 (Handle rustc_const_stable attribute in library feature collector) - rust-lang#95373 (invalid_value lint: detect invalid initialization of arrays) - rust-lang#95430 (Disable #[thread_local] support on i686-pc-windows-msvc) - rust-lang#95544 (Add error message suggestion for missing noreturn in naked function) - rust-lang#95556 (Implement provenance preserving methods on NonNull) - rust-lang#95557 (Fix `thread_local!` macro to be compatible with `no_implicit_prelude`) - rust-lang#95559 (small type system refactoring) - rust-lang#95560 (convert more `DefId`s to `LocalDefId`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

rust-highfive assigned m-ou-se Mar 27, 2022

rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Mar 27, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 27, 2022

dtolnay removed the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Mar 28, 2022

m-ou-se removed their assignment Mar 30, 2022

rust-highfive assigned lcnr Mar 30, 2022

jhpratt requested changes Mar 31, 2022

View reviewed changes

This comment has been minimized.

Sign in to view

dtolnay added 4 commits March 31, 2022 12:34

Handle rustc_const_stable attribute in library feature collector

5d30180

Adjust feature names that disagree on const stabilization version

4246916

Adjust MaybeUninit feature names to avoid changing unstable one

3c8e7b9

Fix feature name of stable parts of strict_provenance

971ecff

dtolnay force-pushed the rustc_const_stable branch from 9479358 to 971ecff Compare March 31, 2022 19:53

jhpratt approved these changes Apr 1, 2022

View reviewed changes

bors 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 Apr 1, 2022

matthiaskrgr mentioned this pull request Apr 1, 2022

Rollup of 7 pull requests #95567

Closed

matthiaskrgr mentioned this pull request Apr 1, 2022

Rollup of 7 pull requests #95572

Closed

Dylan-DPC mentioned this pull request Apr 2, 2022

Rollup of 8 pull requests #95581

Merged

bors merged commit d7a2400 into rust-lang:master Apr 2, 2022

rustbot added this to the 1.61.0 milestone Apr 2, 2022

dtolnay deleted the rustc_const_stable branch April 3, 2022 18:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle rustc_const_stable attribute in library feature collector #95354

Handle rustc_const_stable attribute in library feature collector #95354

dtolnay commented Mar 27, 2022

rust-highfive commented Mar 27, 2022

oli-obk commented Mar 30, 2022

m-ou-se commented Mar 30, 2022

jhpratt commented Mar 30, 2022

jhpratt left a comment

jhpratt Mar 31, 2022

dtolnay Mar 31, 2022

jhpratt Apr 1, 2022

jhpratt Mar 31, 2022

dtolnay Mar 31, 2022

jhpratt Mar 31, 2022

dtolnay Mar 31, 2022

This comment has been minimized.

dtolnay commented Mar 31, 2022

lcnr commented Apr 1, 2022

bors commented Apr 1, 2022

Handle rustc_const_stable attribute in library feature collector #95354

Handle rustc_const_stable attribute in library feature collector #95354

Conversation

dtolnay commented Mar 27, 2022

rust-highfive commented Mar 27, 2022

oli-obk commented Mar 30, 2022

m-ou-se commented Mar 30, 2022

jhpratt commented Mar 30, 2022

jhpratt left a comment

Choose a reason for hiding this comment

jhpratt Mar 31, 2022

Choose a reason for hiding this comment

dtolnay Mar 31, 2022

Choose a reason for hiding this comment

jhpratt Apr 1, 2022

Choose a reason for hiding this comment

jhpratt Mar 31, 2022

Choose a reason for hiding this comment

dtolnay Mar 31, 2022

Choose a reason for hiding this comment

jhpratt Mar 31, 2022

Choose a reason for hiding this comment

dtolnay Mar 31, 2022

Choose a reason for hiding this comment

This comment has been minimized.

dtolnay commented Mar 31, 2022

lcnr commented Apr 1, 2022

bors commented Apr 1, 2022