-
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
Introduce stricter checks for might_permit_raw_init under a debug flag #97323
Conversation
Some changes occured to rustc_codegen_cranelift cc @bjorn3 Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
I'll leave the variant checks for future work. Was initially going to try and get them in now (so it's not as much breakage to add them later), but I figure adding more panics on UB when you're using a debugging flag specifically to panic on UB is pretty justifiable. That, and I want to get the infrastructure in here sooner than later. Will clean up this PR to just do the array and primitive checks. |
e68b692
to
d59cc92
Compare
@rustbot ready |
&& !layout.might_permit_raw_init( | ||
self, | ||
/*zero:*/ false, | ||
self.tcx.sess.opts.debugging_opts.strict_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.
somewhat annoying to pass this everywhere, when self
is also passed. Though HasDataLayout
doesn't have a useful way to get at this.
maybe add a field to TargetDataLayout
for that bool?
Idk, doesn't seem great either. I guess let's roll with the PR as it is.
@bors r+ |
📌 Commit d59cc92d7a30f0b4b7d9e192ca0e165a306f61ef has been approved by |
oh lol, apologies, that's funny timing |
Cc #66151 |
@bors r- We're not in a rush for this feature I think, so let's fix that nit before landing. :) |
And also thanks a lot @5225225 for doing this, I quite like the idea of opting-in to the more strict checks. :D FWIW, as @oli-obk proposed once, there is an elegant way to get the "fully strict" check but it requires more work and no code sharing with the non-strict case: fire up an |
690792e
to
3b7dc2d
Compare
Okay, I've fixed the formatting in the cranelift code, moved the And yeah, the "actually make an allocation and then ask the interpreter if it's valid" seems like the cleanest solution. |
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.
cg_clif changes LGTM
3b7dc2d
to
cfab521
Compare
cfab521
to
df6e965
Compare
df6e965
to
dd9f31d
Compare
@bors r+ |
📌 Commit dd9f31d has been approved by |
Rollup of 5 pull requests Successful merges: - rust-lang#93604 (Make llvm-libunwind a per-target option) - rust-lang#97026 (Change orderings of `Debug` for the Atomic types to `Relaxed`.) - rust-lang#97105 (Add tests for lint on type dependent on consts) - rust-lang#97323 (Introduce stricter checks for might_permit_raw_init under a debug flag ) - rust-lang#97379 (Add aliases for `current_dir`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is intended to be a version of the strict checks tried out in #79296, but also checking number validity (under the assumption that
let _ = std::mem::uninitialized::<u32>()
is UB, which seems to be what rust-lang/unsafe-code-guidelines#71 is leaning towards.)