Skip to content
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

Merged
merged 4 commits into from
Mar 27, 2022
Merged

Stabilize const_ptr_offset #93957

merged 4 commits into from
Mar 27, 2022

Conversation

SaltyKitkat
Copy link
Contributor

Close #71499

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 13, 2022
@rust-highfive
Copy link
Collaborator

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 rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 13, 2022
@SaltyKitkat
Copy link
Contributor Author

@rustbot modify labels: +T-libs-api

@rustbot rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Feb 13, 2022
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@SaltyKitkat SaltyKitkat marked this pull request as draft February 13, 2022 08:42
@SaltyKitkat SaltyKitkat marked this pull request as ready for review February 13, 2022 10:41
@scottmcm scottmcm added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Feb 18, 2022
@scottmcm
Copy link
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

@rust-highfive rust-highfive assigned m-ou-se and unassigned scottmcm Feb 18, 2022
@SaltyKitkat
Copy link
Contributor Author

Anything I can do to push forward?

@m-ou-se
Copy link
Member

m-ou-se commented Mar 9, 2022

I've started the FCP process on the tracking issue: #71499 (comment)

@m-ou-se m-ou-se added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 9, 2022
@dtolnay
Copy link
Member

dtolnay commented Mar 26, 2022

I bumped the since = "1.60.0" attributes to since = "1.61.0" since 1.60 has branched into beta already.

Thanks SaltyKitkat!

@bors r+

@bors
Copy link
Contributor

bors commented Mar 26, 2022

📌 Commit e5d1d97 has been approved by dtolnay

@bors
Copy link
Contributor

bors commented Mar 26, 2022

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 26, 2022
@dtolnay dtolnay removed the S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. label Mar 26, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 26, 2022
@Dylan-DPC
Copy link
Member

failed in rollup ci

@bors r-

@bors bors 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 Mar 26, 2022
@dtolnay
Copy link
Member

dtolnay commented Mar 27, 2022

That's a bug in rustc_passes as far as I can tell. rustc_const_stable attributes are not being handled correctly as library features by compiler/rustc_passes/src/lib_features.rs. I'll put up a fix.

@dtolnay
Copy link
Member

dtolnay commented Mar 27, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Mar 27, 2022

📌 Commit 333756f has been approved by dtolnay

@bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 27, 2022
@bors
Copy link
Contributor

bors commented Mar 27, 2022

⌛ Testing commit 333756f with merge 223b58e...

@bors
Copy link
Contributor

bors commented Mar 27, 2022

☀️ Test successful - checks-actions
Approved by: dtolnay
Pushing 223b58e to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 27, 2022
@bors bors merged commit 223b58e into rust-lang:master Mar 27, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 27, 2022
@SaltyKitkat SaltyKitkat deleted the stablize_const_ptr_offset branch March 28, 2022 01:33
@rust-timer
Copy link
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.
@tmandry
Copy link
Member

tmandry commented Apr 29, 2022

@rustbot label +relnotes

@rustbot rustbot added the relnotes Marks issues that should be documented in the release notes of the next release. label Apr 29, 2022
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.
@dtolnay dtolnay self-assigned this Mar 24, 2024
@RalfJung
Copy link
Member

I only just noticed that we have a rustc_allow_const_fn_unstable(const_mut_refs) here. That's no good, this should not have been stabilized.

@rust-lang/libs-api in the future, when stabilizing anything with rustc_allow_const_fn_unstable, please let's make sure this is explicitly approved by at least @rust-lang/wg-const-eval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. relnotes Marks issues that should be documented in the release notes of the next release. 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. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking Issue for making ptr offset methods "const fn"