never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn)#100081
Conversation
rustbot
added
the
T-compiler
|
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) |
rust-highfive
added
the
S-waiting-on-review
|
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. |
RalfJung
force-pushed
the
unused-unsafe-in-unsafe-fn
branch
from
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 :) |
LeSeulArtichaut
left a comment
LeSeulArtichaut
left a comment
There was a problem hiding this comment.
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 |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
…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
9 participants
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.