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

Tracking Issue for const_intrinsic_copy #80697

Closed
6 of 7 tasks
usbalbin opened this issue Jan 4, 2021 · 15 comments · Fixed by #97276 or #130762
Closed
6 of 7 tasks

Tracking Issue for const_intrinsic_copy #80697

usbalbin opened this issue Jan 4, 2021 · 15 comments · Fixed by #97276 or #130762
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@usbalbin
Copy link
Contributor

usbalbin commented Jan 4, 2021

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

@usbalbin usbalbin added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jan 4, 2021
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 5, 2021
…=oli-obk

const_intrinsic_copy - Add Reference to tracking issue

Add reference to tracking issue rust-lang#80697 for feature gate added in previous PR rust-lang#79684
@m-ou-se m-ou-se added the Libs-Tracked Libs issues that are tracked on the team's project board. label Jan 6, 2021
@usbalbin
Copy link
Contributor Author

usbalbin commented Mar 4, 2021

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

@RalfJung
Copy link
Member

RalfJung commented Mar 5, 2021

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

@RalfJung

This comment has been minimized.

@RalfJung

This comment has been minimized.

@joshtriplett
Copy link
Member

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

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

@rfcbot
Copy link

rfcbot commented 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:

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 proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jan 26, 2022
@RalfJung
Copy link
Member

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

@joshtriplett
Copy link
Member

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

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 23, 2022
@rfcbot
Copy link

rfcbot commented Feb 23, 2022

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

@rfcbot rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label Mar 5, 2022
@rfcbot
Copy link

rfcbot commented Mar 5, 2022

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.

@rfcbot rfcbot added to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Mar 5, 2022
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Mar 17, 2022
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jun 8, 2022
…-copy, r=dtolnay

Stabilize `const_intrinsic_copy`

FCP has been completed: rust-lang#80697 (comment)
Closes rust-lang#80697
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jun 8, 2022
…-copy, r=dtolnay

Stabilize `const_intrinsic_copy`

FCP has been completed: rust-lang#80697 (comment)
Closes rust-lang#80697
@bors bors closed this as completed in f6b04ad Jun 8, 2022
@Dylan-DPC
Copy link
Member

Opening since stablisation was reverted in #117905

@Dylan-DPC Dylan-DPC reopened this Jun 1, 2024
@Noratrieb Noratrieb removed 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. labels Jun 1, 2024
@RalfJung
Copy link
Member

RalfJung commented 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?

@RalfJung RalfJung added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Sep 4, 2024
@dtolnay
Copy link
Member

dtolnay commented 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.

@dtolnay dtolnay removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Sep 4, 2024
@RalfJung
Copy link
Member

Stabilization PR is up: #130762

compiler-errors added a commit to compiler-errors/rust that referenced this issue 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.
@bors bors closed this as completed in 64aa4c6 Sep 24, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue 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.
@tgross35
Copy link
Contributor

For posterity: the constness of some NonNull 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:

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);
}

github-actions bot pushed a commit to rust-lang/miri that referenced this issue 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
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants