`undocumented_unsafe_blocks` false positive despite `accept-comment-above-attributes = true`

[joshlf]

Summary

undocumented_unsafe_blocks fires when attribute follows safety comment even though accept-comment-above-attributes = true is set in clippy.toml.

See google/zerocopy#2753 for full context and another example of the failure.

Lint Name

undocumented_unsafe_blocks

Reproducer

I tried this code:

        // We use `transmute` instead of an `as` cast since Miri (with strict
        // provenance enabled) notices and complains that an `as` cast creates a
        // pointer with no provenance. Miri isn't smart enough to realize that
        // we're only executing this branch when we're constructing a zero-sized
        // `Box`, which doesn't require provenance.
        //
        // SAFETY: any initialized bit sequence is a bit-valid `*mut u8`. All
        // bits of a `usize` are initialized.
        #[allow(unknown_lints)] // For `integer_to_ptr_transmutes`
        #[allow(clippy::useless_transmute, integer_to_ptr_transmutes)]
        let dangling = unsafe { mem::transmute::<usize, *mut u8>(align) };

I saw this happen:

error: unsafe block missing a safety comment
   --> src/util/mod.rs:375:24
    |
375 |         let dangling = unsafe { mem::transmute::<usize, *mut u8>(align) };
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = 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
note: the lint level is defined here
   --> src/lib.rs:272:5
    |
272 |     clippy::undocumented_unsafe_blocks,
    |    

I expected to see this happen:

No lint triggered

Version

rustc 1.93.0-nightly (20383c9f1 2025-11-03)
binary: rustc
commit-hash: 20383c9f1d84eb9b9c6668a1668ef68a81eae274
commit-date: 2025-11-03
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.3

Here's the toolchain version we're running on main, where this failure is not showing up. Presumably this is a regression introduced between these two toolchain versions.

rustc 1.92.0-nightly (53a741fc4 2025-10-16)
binary: rustc
commit-hash: 53a741fc4b8cf2d8e7b1b2336ed8edf889db84f4
commit-date: 2025-10-16
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.3

Additional Labels

No response

[zihan0822]

this is caused by the trailing comment after attribute

[joshlf]

this is caused by the trailing comment after attribute

Ah I see. Would there be any way to consider them part of the same comment or to annotate the same unsafe block? If not, would it be possible to detect this case and emit help text suggesting merging the comments as a fix?