Stabilize const_ptr_offset#93957
Merged
bors merged 4 commits intorust-lang:masterfrom Mar 27, 2022
SaltyKitkat:stablize_const_ptr_offset
Merged
Stabilize const_ptr_offset#93957bors merged 4 commits intorust-lang:masterfrom SaltyKitkat:stablize_const_ptr_offset
bors merged 4 commits intorust-lang:masterfrom
SaltyKitkat:stablize_const_ptr_offset
Conversation
rustbot
added
the
T-compiler
Contributor
|
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. |
rust-highfive
added
the
S-waiting-on-review
Contributor
Author
|
@rustbot modify labels: +T-libs-api |
rustbot
added
the
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.
scottmcm
added
the
needs-fcp
Member
|
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 |
Contributor
Author
|
Anything I can do to push forward? |
Member
|
I've started the FCP process on the tracking issue: #71499 (comment) |
m-ou-se
added
S-waiting-on-fcp
Member
|
I bumped the Thanks SaltyKitkat! @bors r+ |
Collaborator
|
📌 Commit e5d1d97 has been approved by |
Collaborator
|
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
bors
added
the
S-waiting-on-bors
dtolnay
approved these changes
Mar 26, 2022
dtolnay
removed
the
S-waiting-on-fcp
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Mar 26, 2022
…et, r=dtolnay Stabilize const_ptr_offset Close rust-lang#71499
Member
bors
added
S-waiting-on-author
Member
|
That's a bug in rustc_passes as far as I can tell. |
dtolnay
approved these changes
Mar 27, 2022
Member
|
@bors r+ |
Collaborator
|
📌 Commit 333756f has been approved by |
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Collaborator
|
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 |
yvt
added a commit
to r3-os/r3
that referenced
this pull request
Mar 29, 2022
The `const_ptr_offset` feature was stabilized by <rust-lang/rust#93957>.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 1, 2022
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.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 1, 2022
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.
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Apr 2, 2022
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.
Member
|
@rustbot label +relnotes |
rustbot
added
the
relnotes
tmandry
added a commit
to tmandry/relnotes
that referenced
this pull request
Apr 29, 2022
Would have caught rust-lang/rust#93957, which had the actual FCP on a tracking issue.
Member
|
I only just noticed that we have a @rust-lang/libs-api in the future, when stabilizing anything with |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Close #71499