#[allow(unsafe_code)] should be allowed after SAFETY: docs

[Jake-Shadle]

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

[Centri3]

Considering #10832 is being worked on, I think this is reasonable as well. @rustbot claim