revert stabilization of const_intrinsic_copy #117905
Merged
Conversation
This file contains 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
|
r? @thomcc (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
@bors try |
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.)
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
no-const-mut
branch
from
e517f1f
to
73ae788
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
no-const-mut
branch
from
73ae788
to
215e10e
Compare
This comment has been minimized.
This comment has been minimized.
|
Yeah that is blocked on rust-lang/stdarch#1497.
|
|
@bors try |
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.)
|
This has been const-stable for over a year... |
|
Yes 🙈 But it's also nearly impossible to use on stable in a way that's not UB. I am curious if we'll find any uses. |
|
I feel like I've used the pointer versions in const before, but I can't find the code so I might be mistaken (it also may have been with unstable features enabled). Either way, this deserves a crater run, for sure. |
|
What's the point if we're going to move on stabilizing |
|
☀️ Try build successful - checks-actions |
We don't know how soon "soon" really is. Oli added #79738 as a blocker and he was working on fixing that but the latest attempt in #116564 has perf issues. Also I feel better if we can stabilize this "cleanly" rather than already having gaps in our checks... @craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
Okay, it's not happening soon but rather Soon™ makes this more understandable. |
fwiw, if we land this, I think simply breaking code by moving the const-eval checks that allow it behind |
|
What's the difference between moving this behind Sadly I don't think we have the infrastructure to make this "unstable with a forward-compat lint". If crater finds significant usage then I'll just close the PR and we live with our mistake. My hypothesis still is that ~nobody is using this in |
maybe it's just ideological, I suppose? making a |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry ld: unknown options: -ios_simulator_version_min |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (256b6fb): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 663.272s -> 662.479s (-0.12%) |
GuillaumeGomez
pushed a commit
to GuillaumeGomez/rustc_codegen_gcc
that referenced
this pull request
Feb 15, 2024
compile-time evaluation: detect writes through immutable pointers This has two motivations: - it unblocks rust-lang/rust#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable" - it would detect the UB that was uncovered in rust-lang/rust#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already. The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers. I just hope perf works out.
|
If I read correctly this comment, this breaking change should be mentioned in next release notes @rustbot label +relnotes |
rustbot
added
the
relnotes
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this pull request
Apr 7, 2024
compile-time evaluation: detect writes through immutable pointers This has two motivations: - it unblocks rust-lang/rust#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable" - it would detect the UB that was uncovered in rust-lang/rust#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already. The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers. I just hope perf works out.
RalfJung
pushed a commit
to RalfJung/rust-analyzer
that referenced
this pull request
Apr 27, 2024
compile-time evaluation: detect writes through immutable pointers This has two motivations: - it unblocks rust-lang/rust#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable" - it would detect the UB that was uncovered in rust-lang/rust#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already. The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers. I just hope perf works out.
7 tasks
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 17, 2024
…inter, r=<try> make writes_through_immutable_pointer a hard error This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure. Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc `@rust-lang/lang` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 24, 2024
…pointer, r=compiler-errors make writes_through_immutable_pointer a hard error This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure. Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc `@rust-lang/lang` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 24, 2024
…pointer, r=compiler-errors make writes_through_immutable_pointer a hard error This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure. Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 25, 2024
Rollup merge of rust-lang#129199 - RalfJung:writes_through_immutable_pointer, r=compiler-errors make writes_through_immutable_pointer a hard error This turns the lint added in rust-lang#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang#117905. Still, let's do a crater run just to be sure. Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang#129195 which is already nominated for discussion.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Aug 26, 2024
…r=compiler-errors make writes_through_immutable_pointer a hard error This turns the lint added in rust-lang/rust#118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in rust-lang/rust#117905. Still, let's do a crater run just to be sure. Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of rust-lang/rust#129195 which is already nominated for discussion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
@rust-lang/wg-const-eval I don't know what we were thinking when we approved #97276... const-eval isn't supposed to be able to mutate anything yet! It's also near impossible to actually call
copyin const on stable since&mutexpressions are generally unstable. However, there's one exception...Inside
static mut, we accept some&mutsince ~forever, to makestatic mut FOO: &mut [T] = &mut [...];work. We reject any attempt to actually write to that mutable reference though... except for thecopyfunctions.I think we should revert stabilizing these functions that take
*mut, and then re-stabilize them together withptr.writeonce 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.)