-
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
never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn) #100081
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
r? @wesleywiser (rust-highfive has picked a reviewer for you, use r? to override) |
Note that I barely understand the code I am touching here, so I hope this makes sense. I did this entirely based on getting the tests to behave the way I want them to... |
Ah, that conflict is a bummer. I can rebase but then I cannot locally test this any more due to #100062. |
16ef42f
to
3e44ca9
Compare
This probably conflicts with #99379 |
@LeSeulArtichaut ah, that's why the changes I had to do in the two unsafety checkers are so different. |
I'd still expect the change to THIR unsafeck to be easier to reason about, simply because we don't have to do a separate visit of the HIR to check for unused blocks :) |
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.
The changes make sense to me, for what it's worth.
This appears pretty clearly in the first commit, but for the record, the way I understand this change is that since we want to consider that we have #[deny(unsafe_op_in_unsafe_fn)]
, which means that we always have SomeDisallowedInUnsafeFn
.
Yeah after doing all this I realized that |
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
r? compiler |
r? compiler |
…n, r=jackh726 never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn) Judging from rust-lang#71668 (comment) the consensus nowadays seems to be that we should never consider an unsafe block unused if it was required with `deny(unsafe_op_in_unsafe_fn)`, no matter whether that lint is actually enabled or not. So let's adjust rustc accordingly. The first commit does the change, the 2nd does some cleanup.
…n, r=jackh726 never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn) Judging from rust-lang#71668 (comment) the consensus nowadays seems to be that we should never consider an unsafe block unused if it was required with `deny(unsafe_op_in_unsafe_fn)`, no matter whether that lint is actually enabled or not. So let's adjust rustc accordingly. The first commit does the change, the 2nd does some cleanup.
Rollup of 9 pull requests Successful merges: - rust-lang#99576 (Do not allow `Drop` impl on foreign fundamental types) - rust-lang#100081 (never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn)) - rust-lang#100208 (make NOP dyn casts not require anything about the vtable) - rust-lang#100494 (Cleanup rustdoc themes) - rust-lang#100522 (Only check the `DefId` for the recursion check in MIR inliner.) - rust-lang#100592 (Manually implement Debug for ImportKind.) - rust-lang#100598 (Don't fix builtin index when Where clause is found) - rust-lang#100721 (Add diagnostics lints to `rustc_type_ir` module) - rust-lang#100731 (rustdoc: count deref and non-deref as same set of used methods) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…safe_fn, r=RalfJung Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024 This was previously FCPed: rust-lang#71668 (comment) There were two blocking requirements: * Fix the `unused_unsafe` lint, done in rust-lang#100081 * Have `cargo fix` able to fix the lint, done in rust-lang#112017
…r=RalfJung Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024 This was previously FCPed: rust-lang/rust#71668 (comment) There were two blocking requirements: * Fix the `unused_unsafe` lint, done in rust-lang/rust#100081 * Have `cargo fix` able to fix the lint, done in rust-lang/rust#112017
…r=RalfJung Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024 This was previously FCPed: rust-lang/rust#71668 (comment) There were two blocking requirements: * Fix the `unused_unsafe` lint, done in rust-lang/rust#100081 * Have `cargo fix` able to fix the lint, done in rust-lang/rust#112017
…r=RalfJung Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024 This was previously FCPed: rust-lang/rust#71668 (comment) There were two blocking requirements: * Fix the `unused_unsafe` lint, done in rust-lang/rust#100081 * Have `cargo fix` able to fix the lint, done in rust-lang/rust#112017
Judging from #71668 (comment) the consensus nowadays seems to be that we should never consider an unsafe block unused if it was required with
deny(unsafe_op_in_unsafe_fn)
, no matter whether that lint is actually enabled or not. So let's adjust rustc accordingly.The first commit does the change, the 2nd does some cleanup.