Lints about `unsafe {}` blocks propagate inside macros

[poliorcetics]

Coming from #74200.

I used #![deny(unsafe_op_in_unsafe_fn)] in std/panicking.rs. This raised an error about a missing unsafe {} block in std/thread/local.rs. Adding it raised a warning about extraneous unsafe {} in other parts of the code. This forced me to use #[allow(unused_unsafe)].

It was noted that lints like those (whatever those is) should maybe not propagate inside macros.

cc @Mark-Simulacrum who raised the point in the first place

[RalfJung]

It is expected behavior that unsafe blocks in a macro need #[allow(unused_unsafe)] to not get a warning when the macro is itself used inside an unsafe block. Sounds like that is what happened here?

[RalfJung]

I think the fix for this would be something like "unsafety hygiene". I am not sure if that is on the roadmap, but it is probably not backwards compatible so it could be done only for macro macros (not macro_rules! macros).

Cc @petrochenkov

[Mark-Simulacrum]

Unsafety hygiene would be the "next step", but to start I would just want to not warn about unsafe inside macros if they're already in an unsafe context -- that seems reasonable. I imagine that would be backwards compatible? We could also just silence "unused_unsafe" entirely inside macros, I guess, which would be easier.

[jyn514]

i think this was fixed by #100081

[kadiwa4]

current output (nightly 1.74.0 2023-09-26):

macro_rules! spooky_macro {
    () => {
        unsafe { core::mem::zeroed::<u32>() }
    };
}

fn main() {
    // case 1: warning: unnecessary `unsafe` block
    unsafe {
        let _: [u8; 4] = core::mem::transmute(spooky_macro!());
    }
}

pub unsafe fn spooky_fn() {
    // case 2: Fixed! No warning.
    let _: [u8; 4] = core::mem::transmute(spooky_macro!());
}

So yes, since this issue was specifically filed about case 2, you could consider it fixed.

There are two other issues about the same kind of problem: #49112 and #94912