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

Stabilize const_intrinsic_copy #97276

Merged
merged 1 commit into from
Jun 8, 2022

Conversation

JohnTitor
Copy link
Member

FCP has been completed: #80697 (comment)
Closes #80697

@rust-highfive
Copy link
Collaborator

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rustbot rustbot added T-compiler Relevant to the compiler 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. labels May 22, 2022
@rust-highfive
Copy link
Collaborator

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 22, 2022
@JohnTitor
Copy link
Member Author

r? rust-lang/libs-api

@rust-highfive rust-highfive assigned dtolnay and unassigned kennytm Jun 7, 2022
Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@dtolnay
Copy link
Member

dtolnay commented Jun 7, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Jun 7, 2022

📌 Commit 23a0e3e has been approved by dtolnay

@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 Jun 7, 2022
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
@Dylan-DPC
Copy link
Member

failed in rollup ci
need to remove the feature gate from test(s)

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 8, 2022
@JohnTitor JohnTitor force-pushed the stabilize-const-intrinsic-copy branch from 23a0e3e to 2b58e63 Compare June 8, 2022 11:17
@Dylan-DPC
Copy link
Member

@bors r=dtolnay

@bors
Copy link
Contributor

bors commented Jun 8, 2022

📌 Commit 2b58e63 has been approved by dtolnay

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 8, 2022
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
@bors bors merged commit f6b04ad into rust-lang:master Jun 8, 2022
@rustbot rustbot added this to the 1.63.0 milestone Jun 8, 2022
@JohnTitor JohnTitor deleted the stabilize-const-intrinsic-copy branch June 8, 2022 22:38
@JohnTitor JohnTitor added the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 21, 2022
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
@RalfJung
Copy link
Member

@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 const was very deliberately kept unstable.

@RalfJung
Copy link
Member

Oh, sorry for that. There was prior approval in #80697 (comment), just not in this PR. My bad!

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
Labels
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-compiler Relevant to the compiler 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking Issue for const_intrinsic_copy
8 participants