Tracking Issue for const_intrinsic_copy

[usbalbin]

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 and ptr::copy_nonoverlapping as const fn: Make copy[_nonoverlapping] const #79684
  • Link to this issue in feature gate: const_intrinsic_copy - Add Reference to tracking issue #80699
• Also constify copy_to, copy_from and friends : Constify copy related functions #83091
• Final commenting period (FCP)
• Stabilization PR: Stabilize const_intrinsic_copy #97276
• De-stabilization PR: revert stabilization of const_intrinsic_copy #117905
• TODO: new stabilization PR, once Tracking issue for &mut T in const contexts (const_mut_refs) #57349 is stable

[usbalbin]

@RalfJung with #81238 merged, is the concern about "bringing back debug assertions" resolved as - we won't bring them back?

[RalfJung]

Yeah I guess for now we won't bring them back.

[joshtriplett]

Seems reasonable, assuming that @rust-lang/wg-const-eval is fine with it.

@rfcbot merge
@rfcbot concern confirm-with-wg-const-eval

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

Concerns:

• confirm-with-wg-const-eval resolved 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.

[RalfJung]

Fine from my side -- these are all conceptually simple functions and their implementation has been battle-tested a lot in Miri.

[joshtriplett]

@rfcbot resolve confirm-with-wg-const-eval

[rfcbot]

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

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[Dylan-DPC]

Opening since stablisation was reverted in #117905

[RalfJung]

@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]

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.