`undocumented_unsafe_blocks` requires incorrect word "SAFETY"

[Kixunil]

Summary

Whether some code is safe or not depends solely on the presence of unsafe keyword. That means unsafe { foo() } can never be safe, however it can be sound. When writing unsafe code blocks documentation is important, however Clippy requires it to start with the wrong word SAFETY, rather than the correct word SOUNDNESS. Attempt to write SOUNDNESS instead leads to an error.

Since I expect that a lot of code is currently using the word SAFETY, rather than changing SAFETY to SOUNDNESS, clippy should just accept SOUNDNESS in addition to SAFETY for now and some kind of transition can be done as a separate lint.

Lint Name

undocumented_unsafe_blocks

Reproducer

I tried this code:

#![deny(clippy::undocumented_unsafe_blocks)]

unsafe extern "C" {
    fn write(fd: i32, ptr: *const u8, len: usize);
}

fn main() {
    const HELLO: &str = "Hello";
    // SOUNDNESS: 1 is a valid fd, pointer obtained from reference that's still live, len obtained
    // from slice
    unsafe { write(1, HELLO.as_ptr(), HELLO.len()) }
}

I saw this happen:

error: unsafe block missing a safety comment
  --> src/main.rs:11:5
   |
11 |     unsafe { write(1, HELLO.as_ptr(), HELLO.len()) }
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = 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

I expected to see this happen: No error

Version

rustc 1.86.0-nightly (ae5de6c75 2025-01-29)
binary: rustc
commit-hash: ae5de6c759cd337ecdb2de4e94f47eaafb5d4606
commit-date: 2025-01-29
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7

Additional Labels

No response

[profetia]

I think SAFETY is where you explain why it is unsafe, regardless of if it is sound but has to be unsafe, or has other reasons to be unsafe