-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rename assert_uninit_valid
intrinsic
#105613
Conversation
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
d2220ff
to
e3537b8
Compare
library/core/src/intrinsics.rs
Outdated
/// | ||
/// This intrinsic does not have a stable counterpart. | ||
#[rustc_const_unstable(feature = "const_assert_type2", issue = "none")] | ||
#[rustc_safe_intrinsic] | ||
pub fn assert_uninit_valid<T>(); | ||
#[cfg(not(bootstrap))] | ||
pub fn assert_ones_valid<T>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reads to me like is about if all bytes being 0b11111111
is valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally it still seems to check uninit, not 0x01.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think the better approach here is probably to document and rename to match what this intrinsic is for: Checking if it is valid to call mem::uninitialized::<T>()
. This whole thing is a wart on a wart, and we should probably just own that this is so special-cased.
Calling it ones_valid
still leads to confusion, because the behavior changes to something else with -Zstrict-init-checks
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think the better approach here is probably to document and rename to match what this intrinsic is for: Checking if it is valid to call mem::uninitialized::().
Agreed. So what would be a good name? assert_mem_uninitialized_valid
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's what I would go for.
This comment has been minimized.
This comment has been minimized.
I think that flag is still quite useful, e.g. for |
It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that.
e3537b8
to
8b2a7da
Compare
library/core/src/intrinsics.rs
Outdated
@@ -959,13 +959,14 @@ extern "rust-intrinsic" { | |||
#[rustc_safe_intrinsic] | |||
pub fn assert_zero_valid<T>(); | |||
|
|||
/// A guard for unsafe functions that cannot ever be executed if `T` has invalid | |||
/// bit patterns: This will statically either panic, or do nothing. | |||
/// A guard for `std::mem::uninitialized`. Checks whether a repeated bit pattern `0x01` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checks whether a repeated bit pattern
0x01
is legal forT
Except if we decide to change the bit pattern (unlikely) or -Zstrict-init-checks
is passed. Yes it's redundant, but it might be better to just say "Checks whether mem::uninitialized
should panic for T
" 🤷
@bors r+ |
…id, r=RalfJung Rename `assert_uninit_valid` intrinsic It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that. This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if rust-lang#100423 lands so removing it may be a bit over eager. r? `@RalfJung`
…id, r=RalfJung Rename `assert_uninit_valid` intrinsic It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that. This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if rust-lang#100423 lands so removing it may be a bit over eager. r? ``@RalfJung``
☀️ Test successful - checks-actions |
Finished benchmarking commit (bdbe392): 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.
CyclesThis benchmark run did not return any relevant results for this metric. |
…, r=RalfJung Rename `assert_uninit_valid` intrinsic It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that. This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if rust-lang#100423 lands so removing it may be a bit over eager. r? `@RalfJung`
This commit fixes compilation errors but not runtime ones. Related changes: rust-lang/rust#104986 rust-lang/rust#105657 rust-lang/rust#105603 rust-lang/rust#105613
…, r=RalfJung Rename `assert_uninit_valid` intrinsic It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that. This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if rust-lang#100423 lands so removing it may be a bit over eager. r? `@RalfJung`
Upgrade our toolchain to `nightly-2023-01-23`. The changes here are related to the following changes: - rust-lang/rust#104986 - rust-lang/rust#105657 - rust-lang/rust#105603 - rust-lang/rust#105613 - rust-lang/rust#105977 - rust-lang/rust#104645
Update the toolchain to use nightly-2023-04-16. Changes were related to the following changes to the toolchain: - rust-lang/rust#108944 - rust-lang/rust#108148 - rust-lang/rust#108471 - rust-lang/rust#109358 - rust-lang/rust#109849 - rust-lang/rust#109819 - rust-lang/rust#109718 - rust-lang/rust#109092 - rust-lang/rust#108856 - rust-lang/rust#105613 - rust-lang/rust#103042 - rust-lang/rust#109716 - rust-lang/rust#108340 - rust-lang/rust#102906 - rust-lang/rust#98112 - rust-lang/rust#108080
It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that.
This is actually not fully correct though, as it does still panic for all uninit with
-Zstrict-init-checks
. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if #100423 lands so removing it may be a bit over eager.r? @RalfJung