Unsafe Loop when using mem::transmute & Unpreventable Due to a Macro

[WillKirkmanM]

Code

#[macro_export]
macro_rules! vpr_as_m128i {
    ($n64:expr, $idx:expr) => {
        unsafe {
            std::mem::transmute::<u128, std::arch::x86_64::__m128i>($[$idx as usize])
        }
    }
}

Current output

// With 'Unsafe' Keyword
unnecessary `unsafe` block
`#[warn(unused_unsafe)]` on by default
Error originated from macro call here
because it's nested under this `unsafe` block
unnecessary `unsafe` block
unnecessary `unsafe` block
Error originated from macro call here
because it's nested under this `unsafe` block

// When Removing the 'Unsafe' Keyword
call to unsafe function `std::intrinsics::transmute` is unsafe and requires unsafe function or block
consult the function's documentation for information on how to avoid undefined behavior.

Desired output

No warning when adding unsafe since transmuting memory goes out of the bounds of the borrow checker.

Rationale and extra context

The problem occurs when using a macro, normally the issue could be avoided by using the recommended #[warn(unused_unsafe)] procedural macro. However, when adding the attribute, it specifies issue #15701:

attributes on expressions are experimental
see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more informationrustc[Click](rust-analyzer-diagnostics-view:/diagnostic message [1]?1#file:///home/will/Documents/Projects/p64/p64-core/src/rsp.rs)

The proposed fix is either to recognise that mem::transmute requires unsafe due to the borrow checker's absence or allow the #[warn(unused_unsafe)] procedural macro to be allowed to be specified with macros. I would prefer the former over the latter.

Other cases

Rust Version

$ rustc --version --verbose
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1

Anything else?

No response

[fmease]

Could you please provide a working reproducer that's more complete but also conceptually more minimal? One that actually calls the macro vpr_as_m128i and that doesn't contain unrelated errors? For example, $[…] is not valid. Also, you pass something of type [usize; 1] to transmute::<u128, …> which expects an u128.

[fmease]

Also, which edition are you using?

[WillKirkmanM]

Also, which edition are you using?

I am using the unsafe tool chain, latest current version

[clubby789]

What do you mean by 'unsafe toolchain' - nightly?

If possible, please provide a playground link with the issue