-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize const_ptr_offset #93957
Stabilize const_ptr_offset #93957
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @scottmcm (or someone else) soon. Please see the contribution instructions for more information. |
@rustbot modify labels: +T-libs-api |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The code here looks reasonable at a quick skim, but I don't see an FCP in the tracking issue, so reassigning to a libs-api member who can actually kick one off r? rust-lang/libs |
Anything I can do to push forward? |
I've started the FCP process on the tracking issue: #71499 (comment) |
I bumped the Thanks SaltyKitkat! @bors r+ |
📌 Commit e5d1d97 has been approved by |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
…et, r=dtolnay Stabilize const_ptr_offset Close rust-lang#71499
That's a bug in rustc_passes as far as I can tell. |
@bors r+ |
📌 Commit 333756f has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (223b58e): comparison url. Summary: This benchmark run did not return any relevant results. 4 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
The `const_ptr_offset` feature was stabilized by <rust-lang/rust#93957>.
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.
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.
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.
@rustbot label +relnotes |
Would have caught rust-lang/rust#93957, which had the actual FCP on a tracking issue.
I only just noticed that we have a @rust-lang/libs-api in the future, when stabilizing anything with |
Close #71499