Bug in handling unsafe_op_in_unsafe_fn

[schreter]

Handling of unsafe_op_in_unsafe_fn warning introduced by #18135 is unfortunately a bit broken (@ChayimFriedman2).

In our project, we deny warnings, which only has an effect on enabled warnings. In edition 2021 (which is the current default) the warning unsafe_op_in_unsafe_fn is not enabled (allow-by-default).

When compiling regularly with #[deny(warnings)], the compiler doesn't complain. However, rust-analyzer produces a lot of warnings/errors for all unsafe-in-unsafe calls in our code (one library in our project being an async executor implementation naturally has a lot of unsafe code).

rust-analyzer version: 0.3.2162-standalone (3b3a87f 2024-10-27)

rustc version: rustc 1.81.0 (eeb90cda1 2024-09-04)

editor or extension: VSCode

relevant settings: (nothing specific, trivial project shows it)

code snippet to reproduce:

The minimal example I came up with is this one:

Contents of main.rs:

#![warn(warnings)] // <- or `deny` - it activates the warning in Edition 2021!
unsafe fn dangerous() {}
unsafe fn call_dangerous() { dangerous(); }
fn main() { unsafe { call_dangerous(); } }

For completeness, here the Cargo.toml:

[package]
name = "test_unsafe"
version = "0.1.0"
edition = "2021"

It seems like the warning is improperly enabled when #[warn(warnings)] or #[deny(warnings)] is in place. It should be only enabled if either edition is set to 2024 or if it's explicitly enabled by #[warn(unsafe_op_in_unsafe_fn)] or #[deny(unsafe_op_in_unsafe_fn)].

Please fix the warning activation and ideally name a workaround for the time being. Thanks in advance.

[ChayimFriedman2]

Note that #![deny(warnings)] isn't a good practice anyway (we still need to fix this issue though).