Description
Summary
It seems the panic_in_result_fn lint cannot be allowed for a single statement or block of code, and must be allowed for the entire function. I'd like to know if this is intentional behavior, or is there a possibility of having it ignored for a specific block of code?
I noticed this after a "fake return edge" was added to the instrument macro in the tracing-attributes crate (tokio-rs/tracing#2270) which triggers the panic_in_result_fn clippy lint in our codebase. I tried to allow the lint for only that block of code, but it seems that the lint can only be allowed for the entire function, which I'd prefer not to do, as it would allow calling panicking code elsewhere in the function. (I'd opened tokio-rs/tracing#2498 on the tracing repo, was suggested that I open an issue here.)
I'm not sure if this specific scenario should be ignored by clippy, as it is triggered by code generated by an external attribute macro.
Reproducer
I tried these code snippets (similar to the code found in tracing):
#![warn(clippy::panic_in_result_fn)]
fn main() -> Result<(), ()> {
if false {
#[allow(clippy::panic_in_result_fn)]
unreachable!();
}
Ok(())
}#![warn(clippy::panic_in_result_fn)]
fn main() -> Result<(), ()> {
#[allow(clippy::panic_in_result_fn)]
if false {
unreachable!();
}
Ok(())
}I expected that clippy would ignore the lint for the specific statement and/or if block.
Instead, clippy still emits the panic_in_result_fn warning.
The only way I'm able to allow the lint is to allow it for the entire function:
#![warn(clippy::panic_in_result_fn)]
#[allow(clippy::panic_in_result_fn)]
fn main() -> Result<(), ()> {
if false {
unreachable!();
}
Ok(())
}Version
rustc 1.68.0 (2c8cc3432 2023-03-06)
binary: rustc
commit-hash: 2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74
commit-date: 2023-03-06
host: aarch64-apple-darwin
release: 1.68.0
LLVM version: 15.0.6
Additional Labels
No response