Description
Feature gate: #![feature(const_intrinsic_copy)]
This is a tracking issue for making the functions ptr::copy
and ptr::copy_nonoverlapping
as well as some related functions const fn
.
Public API
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);
}
Steps / History
- Implementation of
ptr::copy
andptr::copy_nonoverlapping
asconst fn
: Make copy[_nonoverlapping] const #79684- Link to this issue in feature gate: const_intrinsic_copy - Add Reference to tracking issue #80699
Final commenting period (FCP)Stabilization PR: Stabilizeconst_intrinsic_copy
#97276De-stabilization PR: revert stabilization of const_intrinsic_copy #117905TODO: new stabilization PR, once Tracking issue for&mut T
in const contexts (const_mut_refs) #57349 is stable
Activity
Auto merge of rust-lang#80699 - usbalbin:const_copy_tracking_issue, r…
usbalbin commentedon Mar 4, 2021
@RalfJung with #81238 merged, is the concern about "bringing back debug assertions" resolved as - we won't bring them back?
RalfJung commentedon Mar 5, 2021
Yeah I guess for now we won't bring them back.
RalfJung commentedon Jun 14, 2021
RalfJung commentedon Jun 14, 2021
joshtriplett commentedon Jan 26, 2022
Seems reasonable, assuming that @rust-lang/wg-const-eval is fine with it.
@rfcbot merge
@rfcbot concern confirm-with-wg-const-eval
rfcbot commentedon Jan 26, 2022
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
confirm-with-wg-const-evalresolved by Tracking Issue for const_intrinsic_copy #80697 (comment)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.
18 remaining items
RalfJung commentedon Sep 4, 2024
@rust-lang/libs-api with #129195 being in FCP, I think we can move towards re-stabilizing these methods. Copying between raw pointers seems like basic functionality once mutable raw pointers are allowed, so would be nice to ship this all in the same release. Also, since these methods used to be stable, let's make them stable again as soon as we can. :)
Given that you have already approved this above, will this require another FCP or can we just go ahead and make a PR once #129195 lands?
dtolnay commentedon Sep 4, 2024
Like you said, this is already approved from our end. Feel free to make a re-stabilization PR after #129195. We can ping the team again on the PR but that should be enough notice.
RalfJung commentedon Sep 23, 2024
Stabilization PR is up: #130762
Rollup merge of rust-lang#130762 - RalfJung:const_intrinsic_copy, r=d…
Rollup merge of rust-lang#130762 - RalfJung:const_intrinsic_copy, r=d…
Unrolled build for rust-lang#130762
tgross35 commentedon Sep 24, 2024
For posterity: the
const
ness of someNonNull
methods were moved to this gate in #124498, but the tracking issue didn't get updated. They got const stabilized as part of #130762 (with libs-api signoff). Included:Rollup merge of #130762 - RalfJung:const_intrinsic_copy, r=dtolnay