Skip to content

Tracking Issue for nonnull_provenance #135243

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

Open
1 of 4 tasks
RalfJung opened this issue Jan 8, 2025 · 5 comments
Open
1 of 4 tasks

Tracking Issue for nonnull_provenance #135243

RalfJung opened this issue Jan 8, 2025 · 5 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@RalfJung
Copy link
Member

RalfJung commented Jan 8, 2025

Feature gate: #![feature(nonnull_provenance)]

This is a tracking issue for some provenance functions on NonNull that were missed in the initial strict provenance stabilization.

Public API

// core::ptr

impl<T> NonNull<T> {
    pub const fn without_provenance(addr: NonZero<usize>) -> Self;
    pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
    pub fn expose_provenance(self) -> NonZero<usize>;
}

Steps / History

Unresolved Questions

  • None yet.

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

@RalfJung RalfJung added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jan 8, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 9, 2025
…ratt

add missing provenance APIs on NonNull

This adds some provenance APIs that exist on raw pointers but have been forgotten on `NonNull`:
```rust
impl<T> NonNull<T> {
    pub const fn without_provenance(addr: NonZero<usize>) -> Self;
    pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
    pub fn expose_provenance(self) -> NonZero<usize>;
}
```
rust-lang/libs-team#518 is the ACP for the two exposed provenance ones; I forgot to include `without_provenance` there but I hope that, too, is uncontroversial (and anyway this PR only adds things unstably). Cc `@rust-lang/libs-api`

Tracking issue: rust-lang#135243
jhpratt added a commit to jhpratt/rust that referenced this issue Jan 9, 2025
…ratt

add missing provenance APIs on NonNull

This adds some provenance APIs that exist on raw pointers but have been forgotten on `NonNull`:
```rust
impl<T> NonNull<T> {
    pub const fn without_provenance(addr: NonZero<usize>) -> Self;
    pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
    pub fn expose_provenance(self) -> NonZero<usize>;
}
```
rust-lang/libs-team#518 is the ACP for the two exposed provenance ones; I forgot to include `without_provenance` there but I hope that, too, is uncontroversial (and anyway this PR only adds things unstably). Cc ``@rust-lang/libs-api``

Tracking issue: rust-lang#135243
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 9, 2025
Rollup merge of rust-lang#135242 - RalfJung:nonnull-provenance, r=jhpratt

add missing provenance APIs on NonNull

This adds some provenance APIs that exist on raw pointers but have been forgotten on `NonNull`:
```rust
impl<T> NonNull<T> {
    pub const fn without_provenance(addr: NonZero<usize>) -> Self;
    pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
    pub fn expose_provenance(self) -> NonZero<usize>;
}
```
rust-lang/libs-team#518 is the ACP for the two exposed provenance ones; I forgot to include `without_provenance` there but I hope that, too, is uncontroversial (and anyway this PR only adds things unstably). Cc `@rust-lang/libs-api`

Tracking issue: rust-lang#135243
@scottmcm
Copy link
Member

This without_provenance taking NonZero is beautiful, since it means that code (in Rc) that used to be NonNull::new_unchecked(ptr::without_provenance(MAX)) can now be safe 👍

jhpratt added a commit to jhpratt/rust that referenced this issue Jan 11, 2025
…=jhpratt

Use `NonNull::without_provenance` within the standard library

This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (rust-lang#135243).

Close rust-lang#135343
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 11, 2025
Rollup merge of rust-lang#135347 - samueltardieu:push-qvyxtxsqyxyr, r=jhpratt

Use `NonNull::without_provenance` within the standard library

This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (rust-lang#135243).

Close rust-lang#135343
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 14, 2025
Less unsafe in `dangling`/`without_provenance`

This PR was inspired by the new `NonNull::without_provenance` (cc rust-lang#135243 (comment)) since it made me realize that we could write `NonNull::dangling` in completely-safe code using other existing things.

Then doing that led me to a few more places that could be simplified, like now that GVN will optimize Transmute-then-PtrToPtr, we can just implement `ptr::without_provenance` by calling `ptr::without_provenance_mut` since the shipped rlib of `core` ends up with the same single statement as the implementation (thanks to GVN merging the steps) and thus there's no need to duplicate the `transmute` -- and more importantly, no need to repeat a long safety comment.

There did end up being a couple of other changes needed to avoid exploding certain bits of MIR, though -- like `<Box<[i32]>>::default()`'s MIR originally got way worse as certain things didn't inline, or had a bunch of extraneous UbChecks -- so there's a couple of other changes to solve that.
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 15, 2025
Less unsafe in `dangling`/`without_provenance`

This PR was inspired by the new `NonNull::without_provenance` (cc rust-lang#135243 (comment)) since it made me realize that we could write `NonNull::dangling` in completely-safe code using other existing things.

Then doing that led me to a few more places that could be simplified, like now that GVN will optimize Transmute-then-PtrToPtr, we can just implement `ptr::without_provenance` by calling `ptr::without_provenance_mut` since the shipped rlib of `core` ends up with the same single statement as the implementation (thanks to GVN merging the steps) and thus there's no need to duplicate the `transmute` -- and more importantly, no need to repeat a long safety comment.

There did end up being a couple of other changes needed to avoid exploding certain bits of MIR, though -- like `<Box<[i32]>>::default()`'s MIR originally got way worse as certain things didn't inline, or had a bunch of extraneous UbChecks -- so there's a couple of other changes to solve that.
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 16, 2025
Less unsafe in `dangling`/`without_provenance`

This PR was inspired by the new `NonNull::without_provenance` (cc rust-lang#135243 (comment)) since it made me realize that we could write `NonNull::dangling` in completely-safe code using other existing things.

Then doing that led me to a few more places that could be simplified, like now that GVN will optimize Transmute-then-PtrToPtr, we can just implement `ptr::without_provenance` by calling `ptr::without_provenance_mut` since the shipped rlib of `core` ends up with the same single statement as the implementation (thanks to GVN merging the steps) and thus there's no need to duplicate the `transmute` -- and more importantly, no need to repeat a long safety comment.

There did end up being a couple of other changes needed to avoid exploding certain bits of MIR, though -- like `<Box<[i32]>>::default()`'s MIR originally got way worse as certain things didn't inline, or had a bunch of extraneous UbChecks -- so there's a couple of other changes to solve that.
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
…ratt

add missing provenance APIs on NonNull

This adds some provenance APIs that exist on raw pointers but have been forgotten on `NonNull`:
```rust
impl<T> NonNull<T> {
    pub const fn without_provenance(addr: NonZero<usize>) -> Self;
    pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
    pub fn expose_provenance(self) -> NonZero<usize>;
}
```
rust-lang/libs-team#518 is the ACP for the two exposed provenance ones; I forgot to include `without_provenance` there but I hope that, too, is uncontroversial (and anyway this PR only adds things unstably). Cc `@rust-lang/libs-api`

Tracking issue: rust-lang#135243
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
…=jhpratt

Use `NonNull::without_provenance` within the standard library

This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (rust-lang#135243).

Close rust-lang#135343
@RalfJung RalfJung added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label May 22, 2025
@RalfJung
Copy link
Member Author

@rust-lang/libs-api I'd like to nominate this for stabilization. This is the "obvious" way to fill the gaps in the exposed provenance APIs for NonNull; a few functions have simply been forgotten when we did the original stabilization.

@Amanieu
Copy link
Member

Amanieu commented May 22, 2025

@rfcbot merge

@rfcbot
Copy link
Collaborator

rfcbot commented May 22, 2025

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label May 22, 2025
@Amanieu Amanieu removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. I-libs-api-nominated Nominated for discussion during a libs-api team meeting. labels May 22, 2025
@rfcbot rfcbot added disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels May 22, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented May 29, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants