do not use const stability attribute when we don't even need to call the intrinsic in const#1497
Merged
Amanieu merged 1 commit intorust-lang:masterfrom Nov 16, 2023
Merged
Conversation
…the intrinsic in const
Collaborator
|
r? @Amanieu (rustbot has picked a reviewer for you, use r? to override) |
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.)
Member
Author
|
Strangely it looks like my branch is not actually merged in this repo? Did this get rebased? rust-lang projects usually use merging and I find that a lot nicer than rebase -- it preserves which state the repo was in when I actually worked on this branch. Also with rebasing there's no way to detect which of my feature branches have already been merged so I have to delete them all by hand. |
Member
|
I think the repo was configured this way when I inherited it: it doesn't allow merging, only rebasing for PR. I don't have permissions to change the settings though. |
Contributor
|
Ideally there is a setting to autodelete the branch on merge no matter the merge strategy used |
Member
Author
That would help, but doesn't take care of the local versions of these feature branches in my checkouts. |
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.)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Id' like to revert rust-lang/rust#97276 since we didn't actually mean to support writing to mutable references in
const. But that won't work if stdarch uses the stability attribute. I hope we can just remove it here, otherwise this will be a pain to land...