clippy::multiple-unsafe-ops-per-block: detects safe operation as unsafe

[Paladynee]

Summary

taking &raw const or &raw mut of a union field is a safe operation, but the lint detects them as additional unsafe operations when put in an unsafe block along with other unsafe operations.

Reproducer

union AorB {
    a: i64,
    b: u64,
}

#[warn(clippy::multiple_unsafe_ops_per_block)]
fn main() {
    let data = AorB { a: -1 };
    let access = unsafe { (&raw const data.b).read() };
}

Current output:
emits warning

Desired output:
no warnings

Version

rustc 1.93.0-nightly (6647be936 2025-11-09)
binary: rustc
commit-hash: 6647be93640686a2a443a49f15c3390b68c8b5dd
commit-date: 2025-11-09
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.3
clippy 0.1.93 (6647be9364 2025-11-09)

Additional Labels

No response

[Jarcho]

You have both a union field access and a call to <*const T>::read. The error message even points this out:

warning: this `unsafe` block contains 2 unsafe operations, expected only one
  --> src/main.rs:11:18
   |
11 |     let access = unsafe { (&raw const data.b).read() };
   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: unsafe method call occurs here
  --> src/main.rs:11:27
   |
11 |     let access = unsafe { (&raw const data.b).read() };
   |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: union field access occurs here
  --> src/main.rs:11:39
   |
11 |     let access = unsafe { (&raw const data.b).read() };
   |                                       ^^^^^^
   = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.91.0/index.html#multiple_unsafe_ops_per_block
note: the lint level is defined here
  --> src/main.rs:8:8
   |
 8 | #[warn(clippy::multiple_unsafe_ops_per_block)]
   |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Paladynee]

taking &raw const or &raw mut of a union field is a safe operation:

let field_ptr: *const u64 = &raw const data.b;

this compiles without unsafe, and as such, is not an unsafe operation. the only unsafe operation here is the dereference, hence why it shouldn't trigger the lint condition.

[samueltardieu]

Indeed.

@rustbot claim

[Jarcho]

This is only true as of 1.92, which isn't yet stable.