Stabilize const_intrinsic_copy
#97276
Merged
Conversation
This file contains 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
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
rustbot
added
T-compiler
|
r? @kennytm (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
7 tasks
|
r? rust-lang/libs-api |
|
@bors r+ |
|
📌 Commit 23a0e3e has been approved by |
bors
added
S-waiting-on-bors
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jun 8, 2022
…-copy, r=dtolnay Stabilize `const_intrinsic_copy` FCP has been completed: rust-lang#80697 (comment) Closes rust-lang#80697
bors
added
S-waiting-on-author
JohnTitor
force-pushed
the
stabilize-const-intrinsic-copy
branch
from
23a0e3e
to
2b58e63
Compare
|
@bors r=dtolnay |
|
📌 Commit 2b58e63 has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Jun 8, 2022
…-copy, r=dtolnay Stabilize `const_intrinsic_copy` FCP has been completed: rust-lang#80697 (comment) Closes rust-lang#80697
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 8, 2022
Rollup of 5 pull requests Successful merges: - rust-lang#97276 (Stabilize `const_intrinsic_copy`) - rust-lang#97763 (Allow ptr_from_addr_cast to fail) - rust-lang#97846 (Specify DWARF alignment in bits, not bytes.) - rust-lang#97848 (Impl Traits lowering minor refactors) - rust-lang#97865 (remove `BorrowckMode`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
JohnTitor
added
the
relnotes
yvt
added a commit
to r3-os/r3
that referenced
this pull request
Jul 19, 2022
The `const_intrinsic_copy` feature was stabilized by [rust-lang/rust#97276][1]. [1]: rust-lang/rust#97276
yvt
added a commit
to r3-os/r3
that referenced
this pull request
Jul 19, 2022
The `const_intrinsic_copy` feature was stabilized by [rust-lang/rust#97276][1]. [1]: rust-lang/rust#97276
|
@rust-lang/libs-api this should not have landed the way it did. Const-stabilizing intrinsics requires approval from @rust-lang/lang (similar to how exposing any intrinsic on stable requires t-lang approval) and @rust-lang/wg-const-eval... and in this case we would likely have said "no", since any way of mutating mutable references in |
|
Oh, sorry for that. There was prior approval in #80697 (comment), just not in this PR. My bad! |
This was referenced Nov 14, 2023
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.)
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.)
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 6, 2024
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.)
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 6, 2024
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.)
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Feb 8, 2024
revert stabilization of const_intrinsic_copy `@rust-lang/wg-const-eval` I don't know what we were thinking when we approved rust-lang/rust#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.)
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
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.
FCP has been completed: #80697 (comment)
Closes #80697