-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
Summary
PR #8450 changed it so that nothing can appear between the SAFETY:
comment and the unsafe block it is documenting, while the intention behind this change is good, I think it might be too aggressive in the specific case of using a #[allow(unsafe_code)]
on the same unsafe
block being documented.
Reproducer
I tried this code:
// SAFETY: Blah blah blah safety documention
#[allow(unsafe_code)]
unsafe {
// code goes here
}
I expected to see this happen:
No lint is triggered, the safety documentation applies to the immediately following unsafe
block that has one more more attributes on it.
Instead, this happened:
error: unsafe block missing a safety comment
= note: `-D clippy::undocumented-unsafe-blocks` implied by `-D warnings`
= help: consider adding a safety comment on the preceding line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
Moving #[allow(unsafe_code)]
up above the SAFETY
comment no longer triggers the lint, but IMO this is a regression in readability and could lead users to actually increase the scope of an #[allow(unsafe_code)]
rather than having it scoped as tightly as possible.
Version
rustc 1.62.0-nightly (1f7fb6413 2022-04-10)
binary: rustc
commit-hash: 1f7fb6413d6d6c0c929b223e478e44c3db991b03
commit-date: 2022-04-10
host: x86_64-unknown-linux-gnu
release: 1.62.0-nightly
LLVM version: 14.0.0
Additional Labels
No response