-
Notifications
You must be signed in to change notification settings - Fork 920
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
Enable unsafe_ops_in_unsafe_fn
lint in all workspaces
#3044
Enable unsafe_ops_in_unsafe_fn
lint in all workspaces
#3044
Conversation
0c2265d
to
d31060d
Compare
3c3e317
to
a81d7d4
Compare
Whoo, CI is finally green! This PR should be ready for review now (CC @jimblandy). I've tried noting the open questions I'm aware of. :) |
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.
Thank you for taking on this massive change!
I am generally for this change, in a lot of cases it works quite well to highlight where things can actually go wrong. It does increase verbosity, but I think for the most part it's worth it. I think some things can be combined however - I made some comments about adjustments that I think would be worthwhile. But wait for jim's comments before doing anything :)
I think we should keep the wgpu-hal changes. # Safety
blocks are useful for memory based stuff (pointer ops, etc) but for api based stuff it would be a lot of # Safety: the rest of the codebase lead up to this being safe
:) so I don't think would be necessary,
I think I need to clarify: When you say
…I'm referring to a different lint. The #![deny(unsafe_op_in_unsafe_fn)] // We're adding this in this PR!
#[deny(undocumented_unsafe_blocks)] // What @ErichDonGubler suggested in the OP as follow-up work.
pub unsafe fn do_spooky_thing() {
unsafe { *std::ptr::null_mut::<i32>() = 0 }; // Compile error, fires `undocumented_unsafe_blocks`.
// SAFETY: We know what we're doing here, blah blah blah.
unsafe { *std::ptr::null_mut::<i32>() = 0 }; // Works!
} |
fa0ff35
to
782b6b5
Compare
Codecov Report
@@ Coverage Diff @@
## master #3044 +/- ##
==========================================
- Coverage 64.70% 64.65% -0.05%
==========================================
Files 81 81
Lines 38819 39343 +524
==========================================
+ Hits 25117 25438 +321
- Misses 13702 13905 +203
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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.
I still have a couple small changes I would personally make, but this is a much better place to be in, and this is a PR ripe for catching merge conflicts, so lets merge and adjust from there :)
CI is mad about the GL multithreaded example. This may be some combination of not our bug and has always been our bug, but this PR seems to reproduce it reliably. |
…pes}` This commit bundles all of the trivial cases for enabling this lint, where no action is required beyond adding the lint.
Do the simplest mechanical work necessary to enable and satisfy this lint; only put down `unsafe` blocks, don't try to inspect for correctness or anything else.
Do the simplest mechanical work necessary to enable and satisfy this lint; only put down `unsafe` blocks, don't try to inspect for correctness or anything else. N.B.: that there _are_ some adjustments identified that could be made here, like breaking multiple individual `unsafe` operations into their `unsafe` spans. This is left for a follow-up commit.
Do the simplest mechanical work necessary to enable and satisfy this lint; only put down `unsafe` blocks, don't try to inspect for correctness or anything else. N.B.: that there _are_ some adjustments identified that could be made here, like breaking multiple individual `unsafe` operations into their `unsafe` spans. This is left for a follow-up commit.
Unsafe operations can be exhausting to validate by themselves. Therefore, it's often interesting to separate these out so we can justify each individual operation, and let a human reader accumulate and drop supporting safety context in the smallest increments necessary. To that end, this commit can pave the way for future work where we may do something like enable [`clippy::undocumented_unsafe_blocks`], which calls out `unsafe` blocks that do not have a `SAFETY` comment immediately above them. This commit only separates the operations in `unsafe` blocks I added in this same PR; I'm deliberately leaving existing `unsafe` blocks alone, ATM. [`clippy::undocumented_unsafe_blocks`]: https://rust-lang.github.io/rust-clippy/stable/index.html#undocumented_unsafe_blocks
Head branch was pushed to by a user without write access
2c7f9d4
to
f411fa7
Compare
@cwfitzgerald: Just autosquashed into nice (taking care to respect the merging changes you made), and…now CI is passing. 🥲 Merge plz? |
Terrifying |
Totally my bad; this should not have landed. I was using it while chasing down files to change in gfx-rs#3044. :<
Soft dependency on #3184. Commits start at
chore: `warn(unsafe_op_in_unsafe_fn)` for {deno_webgpu,player,wgpu-types}`
.This commit bundles all the trivial cases for enabling the
unsafe_op_in_unsafe_fn
lint added in Rust 1.52, at @jimblandy's encouragement. I recommend doing this review commit-by-commit, for the best experience. I've done my best to separate out line-heavy-but-mechanical changes from ones where logic is actually modified.Open questions for reviewers:
What about large chains of
Lots of pieces ofunsafe
ops?wgpu-hal
involve a sequence of commands to anunsafe
backend. Addingunsafe { ... }
adds a lot of noise in these cases.unsafe
blocks for operations where the justification is, fundamentally, "We know this sequence of commands is fine".wgpu-hal
; maybe file follow-up work in an issue? Sincewgpu-hal
is an individual commit, it should be easy to remove, if needed.SAFETY
comments forunsafe
blocks in the future? I'm going to guess thatwgpu-hal
would be too much effort to even contemplate for this right now, but maybe starting withwgpu
/wgpu-core
might be good?Checklist
cargo clippy
. (Makingclippy
more picky here, so ✅!)RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown
if applicable.Connections
✅ Link to the issues addressed by this PR, or dependent PRs in other repositories
See above!
Description
✅ Describe what problem this is solving, and how it's solved.
The
unsafe_op_in_unsafe_fn
lint can be disallowed to require thatunsafe
expressions insideunsafe
functions still have explicitunsafe
blocks around them, rather thanunsafe fn
acting as a blanketunsafe
block. This encourages maintainership of the project to minimizeunsafe
operation spans, which in turn minimizes the amount of suspect code when problems with unsoundness occur. It also encourages writers and reviewers to acknowledge of whyunsafe
operations are justified across the board; I'm hoping to follow up with increments on enforcing the justification ofunsafe
via theclippy::undocumented_unsafe_blocks
lint (and maybe theclippy::missing_safety_doc
lint) in select parts of the codebase.1Testing
✅ Explain how this change is tested.
Everything still compiles, including CI, so it should be fine here, so long as reviewing humans are happy with it! :)
Footnotes
Unfortunately, it's unlikely that we'll be justifying
wgpu-hal
in any significant percentage soon, but new code could use it, maybe? :) ↩