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

revert stabilization of const_intrinsic_copy #117905

Merged
merged 1 commit into from
Feb 6, 2024

Conversation

RalfJung
Copy link
Member

@rust-lang/wg-const-eval I don't know what we were thinking when we approved #97276... const-eval isn't supposed to be able to mutate anything yet! It's also near impossible to actually call copy in const on stable since &mut expressions are generally unstable. However, there's one exception...

static mut INT: i32 = unsafe {
    let val = &mut [1]; // `&mut` on arrays is allowed in `static mut`
    (val as *mut [i32; 1]).copy_from(&[42], 1);
    val[0]
};

fn main() { unsafe {
    dbg!(INT);
} }

Inside static mut, we accept some &mut since ~forever, to make static mut FOO: &mut [T] = &mut [...]; work. We reject any attempt to actually write to that mutable reference though... except for the copy functions.

I think we should revert stabilizing these functions that take *mut, and then re-stabilize them together with ptr.write once mutable references are stable.

(This will likely fail on PowerPC until rust-lang/stdarch#1497 lands. But we'll need a crater run first anyway.)

@rustbot
Copy link
Collaborator

rustbot commented Nov 14, 2023

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 14, 2023
@RalfJung
Copy link
Member Author

@bors try

@bors
Copy link
Contributor

bors commented Nov 14, 2023

⌛ Trying commit e517f1f with merge 97685c6...

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 14, 2023
revert stabilization of const_intrinsic_copy

`@rust-lang/wg-const-eval`  I don't know what we were thinking when we approved rust-lang#97276... const-eval isn't supposed to be able to mutate anything yet! It's also near impossible to actually call `copy` in const on stable since `&mut` expressions are generally unstable. However, there's one exception...

```rust
static mut INT: i32 = unsafe {
    let val = &mut [1]; // `&mut` on arrays is allowed in `static mut`
    (val as *mut [i32; 1]).copy_from(&[42], 1);
    val[0]
};

fn main() { unsafe {
    dbg!(INT);
} }
```

Inside `static mut`, we accept some `&mut` since ~forever, to make `static mut FOO: &mut [T] = &mut [...];` work. We reject any attempt to actually write to that mutable reference though... except for the `copy` functions.

I think we should revert stabilizing these functions that take `*mut`, and then re-stabilize them together with `ptr.write` once mutable references are stable.

(This will likely fail on PowerPC until rust-lang/stdarch#1497 lands. But we'll need a crater run first anyway.)
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member Author

RalfJung commented Nov 14, 2023 via email

@RalfJung
Copy link
Member Author

@bors try

@bors
Copy link
Contributor

bors commented Nov 14, 2023

⌛ Trying commit 215e10e with merge 1930f26...

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 14, 2023
revert stabilization of const_intrinsic_copy

`@rust-lang/wg-const-eval`  I don't know what we were thinking when we approved rust-lang#97276... const-eval isn't supposed to be able to mutate anything yet! It's also near impossible to actually call `copy` in const on stable since `&mut` expressions are generally unstable. However, there's one exception...

```rust
static mut INT: i32 = unsafe {
    let val = &mut [1]; // `&mut` on arrays is allowed in `static mut`
    (val as *mut [i32; 1]).copy_from(&[42], 1);
    val[0]
};

fn main() { unsafe {
    dbg!(INT);
} }
```

Inside `static mut`, we accept some `&mut` since ~forever, to make `static mut FOO: &mut [T] = &mut [...];` work. We reject any attempt to actually write to that mutable reference though... except for the `copy` functions.

I think we should revert stabilizing these functions that take `*mut`, and then re-stabilize them together with `ptr.write` once mutable references are stable.

(This will likely fail on PowerPC until rust-lang/stdarch#1497 lands. But we'll need a crater run first anyway.)
@thomcc
Copy link
Member

thomcc commented Nov 14, 2023

This has been const-stable for over a year...

@RalfJung
Copy link
Member Author

Yes 🙈

But it's also nearly impossible to use on stable in a way that's not UB. I am curious if we'll find any uses.

@thomcc
Copy link
Member

thomcc commented Nov 14, 2023

I feel like I've used the pointer versions in const before, but I can't find the code so I might be mistaken (it also may have been with unstable features enabled). Either way, this deserves a crater run, for sure.

@workingjubilee
Copy link
Member

What's the point if we're going to move on stabilizing const_mut_refs soon?

@bors
Copy link
Contributor

bors commented Nov 14, 2023

☀️ Try build successful - checks-actions
Build commit: 1930f26 (1930f260edd7e614aa013a0665aa5cfd0ada0501)

@RalfJung
Copy link
Member Author

What's the point if we're going to move on stabilizing const_mut_refs soon?

We don't know how soon "soon" really is. Oli added #79738 as a blocker and he was working on fixing that but the latest attempt in #116564 has perf issues.

Also I feel better if we can stabilize this "cleanly" rather than already having gaps in our checks...

@craterbot check

@craterbot
Copy link
Collaborator

👌 Experiment pr-117905 created and queued.
🤖 Automatically detected try build 1930f26
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 14, 2023
@workingjubilee
Copy link
Member

Okay, it's not happening soon but rather Soon™ makes this more understandable.

@workingjubilee
Copy link
Member

We don't know how soon "soon" really is. Oli added #79738 as a blocker and he was working on fixing that but the latest attempt in #116564 has perf issues.

Also I feel better if we can stabilize this "cleanly" rather than already having gaps in our checks...

fwiw, if we land this, I think simply breaking code by moving the const-eval checks that allow it behind const_mut_refs, with maybe a single-cycle future-incompat warning to give people a heads up, is actually preferable to walking back API changes. Even if it may seem identical, the Rust stability promises apply very strongly to things like "types/API surface", and they are more hazy about execution semantics.

@RalfJung
Copy link
Member Author

What's the difference between moving this behind const_intrinsic_copy vs moving it behind const_mut_refs?

Sadly I don't think we have the infrastructure to make this "unstable with a forward-compat lint". If crater finds significant usage then I'll just close the PR and we live with our mistake. My hypothesis still is that ~nobody is using this in const, or if they do then in a way that is UB (e.g. creating a shared reference and transmuting that to *mut to write to it).

@workingjubilee
Copy link
Member

What's the difference between moving this behind const_intrinsic_copy vs moving it behind const_mut_refs?

maybe it's just ideological, I suppose? making a fn a const fn is a forward-compatible enhancement of the type of the fn according to my internal reasoning, and breaking types is a Hard Limit Unless Unsound, and stripping that is backwards-incompatible.

@matthiaskrgr
Copy link
Member

@bors retry ld: unknown options: -ios_simulator_version_min

@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-review Status: Awaiting review from the assignee but also interested parties. labels Feb 6, 2024
@bors
Copy link
Contributor

bors commented Feb 6, 2024

⌛ Testing commit 0184ca6 with merge 256b6fb...

@bors
Copy link
Contributor

bors commented Feb 6, 2024

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 256b6fb to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 6, 2024
@bors bors merged commit 256b6fb into rust-lang:master Feb 6, 2024
12 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Feb 6, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (256b6fb): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
4.5% [4.5%, 4.5%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.2% [2.2%, 2.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.9% [-3.4%, -2.6%] 4
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 663.272s -> 662.479s (-0.12%)
Artifact size: 308.23 MiB -> 308.22 MiB (-0.00%)

@RalfJung RalfJung deleted the no-const-mut branch February 8, 2024 06:55
GuillaumeGomez pushed a commit to GuillaumeGomez/rustc_codegen_gcc that referenced this pull request Feb 15, 2024
compile-time evaluation: detect writes through immutable pointers

This has two motivations:
- it unblocks rust-lang/rust#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable"
- it would detect the UB that was uncovered in rust-lang/rust#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB

When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already.

The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers.

I just hope perf works out.
@apiraino
Copy link
Contributor

apiraino commented Apr 2, 2024

If I read correctly this comment, this breaking change should be mentioned in next release notes

@rustbot label +relnotes

@rustbot rustbot added the relnotes Marks issues that should be documented in the release notes of the next release. label Apr 2, 2024
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Apr 7, 2024
compile-time evaluation: detect writes through immutable pointers

This has two motivations:
- it unblocks rust-lang/rust#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable"
- it would detect the UB that was uncovered in rust-lang/rust#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB

When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already.

The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers.

I just hope perf works out.
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024
compile-time evaluation: detect writes through immutable pointers

This has two motivations:
- it unblocks rust-lang/rust#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable"
- it would detect the UB that was uncovered in rust-lang/rust#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB

When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already.

The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers.

I just hope perf works out.
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 17, 2024
…inter, r=<try>

make writes_through_immutable_pointer a hard error

This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc `@rust-lang/lang` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 24, 2024
…pointer, r=compiler-errors

make writes_through_immutable_pointer a hard error

This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc `@rust-lang/lang` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 24, 2024
…pointer, r=compiler-errors

make writes_through_immutable_pointer a hard error

This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 25, 2024
Rollup merge of rust-lang#129199 - RalfJung:writes_through_immutable_pointer, r=compiler-errors

make writes_through_immutable_pointer a hard error

This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Aug 26, 2024
…r=compiler-errors

make writes_through_immutable_pointer a hard error

This turns the lint added in rust-lang/rust#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang/rust#117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang/rust#129195 which is already nominated for discussion.
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Sep 24, 2024
…tolnay

stabilize const_intrinsic_copy

Fixes rust-lang#80697

This stabilizes
```rust
mod ptr {
    pub const unsafe fn copy_nonoverlapping<T>(src: *const T, dst: *mut T, count: usize);
    pub const unsafe fn copy<T>(src: *const T, dst: *mut T, count: usize);
}

impl *const T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);
}

impl *mut T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);

    pub const unsafe fn copy_from(self, src: *const T, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize);
}

impl <T> NonNull<T> {
    pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);

    pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
}
```
In particular, this reverts rust-lang#117905, which reverted rust-lang#97276.

The `NonNull` methods are not listed in the tracking issue, they were added to this feature gate in rust-lang#124498. The existing [FCP](rust-lang#80697 (comment)) does not cover them. They are however entirely identical to the `*mut` methods and already stable outside `const`. `@rust-lang/libs-api` please let me know if FCP will be required for the `NonNull` methods.
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Sep 24, 2024
…tolnay

stabilize const_intrinsic_copy

Fixes rust-lang#80697

This stabilizes
```rust
mod ptr {
    pub const unsafe fn copy_nonoverlapping<T>(src: *const T, dst: *mut T, count: usize);
    pub const unsafe fn copy<T>(src: *const T, dst: *mut T, count: usize);
}

impl *const T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);
}

impl *mut T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);

    pub const unsafe fn copy_from(self, src: *const T, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize);
}

impl <T> NonNull<T> {
    pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);

    pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
}
```
In particular, this reverts rust-lang#117905, which reverted rust-lang#97276.

The `NonNull` methods are not listed in the tracking issue, they were added to this feature gate in rust-lang#124498. The existing [FCP](rust-lang#80697 (comment)) does not cover them. They are however entirely identical to the `*mut` methods and already stable outside `const`. ``@rust-lang/libs-api`` please let me know if FCP will be required for the `NonNull` methods.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 24, 2024
Rollup merge of rust-lang#130762 - RalfJung:const_intrinsic_copy, r=dtolnay

stabilize const_intrinsic_copy

Fixes rust-lang#80697

This stabilizes
```rust
mod ptr {
    pub const unsafe fn copy_nonoverlapping<T>(src: *const T, dst: *mut T, count: usize);
    pub const unsafe fn copy<T>(src: *const T, dst: *mut T, count: usize);
}

impl *const T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);
}

impl *mut T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);

    pub const unsafe fn copy_from(self, src: *const T, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize);
}

impl <T> NonNull<T> {
    pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);

    pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
}
```
In particular, this reverts rust-lang#117905, which reverted rust-lang#97276.

The `NonNull` methods are not listed in the tracking issue, they were added to this feature gate in rust-lang#124498. The existing [FCP](rust-lang#80697 (comment)) does not cover them. They are however entirely identical to the `*mut` methods and already stable outside `const`. ``@rust-lang/libs-api`` please let me know if FCP will be required for the `NonNull` methods.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Sep 25, 2024
stabilize const_intrinsic_copy

Fixes rust-lang/rust#80697

This stabilizes
```rust
mod ptr {
    pub const unsafe fn copy_nonoverlapping<T>(src: *const T, dst: *mut T, count: usize);
    pub const unsafe fn copy<T>(src: *const T, dst: *mut T, count: usize);
}

impl *const T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);
}

impl *mut T {
    pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);

    pub const unsafe fn copy_from(self, src: *const T, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize);
}

impl <T> NonNull<T> {
    pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
    pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);

    pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
    pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
}
```
In particular, this reverts rust-lang/rust#117905, which reverted rust-lang/rust#97276.

The `NonNull` methods are not listed in the tracking issue, they were added to this feature gate in rust-lang/rust#124498. The existing [FCP](rust-lang/rust#80697 (comment)) does not cover them. They are however entirely identical to the `*mut` methods and already stable outside `const`. ``@rust-lang/libs-api`` please let me know if FCP will be required for the `NonNull` methods.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. 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-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs Relevant to the library 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.