Skip to content

Stabilize const_ptr_offset #93957

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
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 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, or significant enough to need a team 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
Collaborator

bors commented Mar 26, 2022

📌 Commit e5d1d97 has been approved by dtolnay

@bors
Copy link
Collaborator

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
Collaborator

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
Collaborator

bors commented Mar 27, 2022

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

@bors
Copy link
Collaborator

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, or significant enough to need a team 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"