Skip to content

clippy::missing_panics_doc still triggering even with expect or allow on individual unwraps #14534

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
hasezoey opened this issue Apr 3, 2025 · 2 comments · May be fixed by #14547
Open

clippy::missing_panics_doc still triggering even with expect or allow on individual unwraps #14534

hasezoey opened this issue Apr 3, 2025 · 2 comments · May be fixed by #14547
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have

Comments

@hasezoey
Copy link

hasezoey commented Apr 3, 2025

Summary

I have some public functions in a public struct which make use of checked, infallible .unwrap()s, which clippy correctly warned about missing # Panics docs, but when adding #[expect(clippy::missing_panics_doc)] above the .unwrap() line, as suggested in the website, it still complained about missing # Panics section on the same line and additionally about a unfulfilled expect.

Playground link

In case the website changes, here is what i reference:

Individual panics within a function can be ignored with #[expect] or #[allow]:

pub fn will_not_panic(x: usize) {
   #[expect(clippy::missing_panics_doc, reason = "infallible")]
   let y = NonZeroUsize::new(1).unwrap();

   // If any panics are added in the future the lint will still catch them
}

Lint Name

clippy::missing_panics_doc

Reproducer

I tried this code:

#![warn(clippy::missing_panics_doc)]

pub struct T;

impl T {
    pub fn some_fn(&self, buf: &[u8]) -> Result<(), ()> {
        #[expect(clippy::missing_panics_doc, reason = "test")]
        let _ = Self::some_other_fn(buf).unwrap();
        
        Ok(())
    }
    
    fn some_other_fn(buf: &[u8]) -> Result<usize, ()> {
        const USIZE_LEN: usize = size_of::<usize>();
        if buf.len() < USIZE_LEN {
            return Err(());
        }

        let bytes: [u8; USIZE_LEN] = buf[..USIZE_LEN].try_into().unwrap();

        Ok(usize::from_ne_bytes(bytes))
    }
}

fn main() {
    let t = T;
    let buf = &10usize.to_ne_bytes();
    let _ = t.some_fn(buf);
}

I saw this happen:

warning: docs for function which may panic missing `# Panics` section
 --> src/main.rs:6:5
  |
6 |     pub fn some_fn(&self, buf: &[u8]) -> Result<(), ()> {
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: first possible panic found here
 --> src/main.rs:8:17
  |
8 |         let _ = Self::some_other_fn(buf).unwrap();
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#missing_panics_doc
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![warn(clippy::missing_panics_doc)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: this returns a `Result<_, ()>`
 --> src/main.rs:6:5
  |
6 |     pub fn some_fn(&self, buf: &[u8]) -> Result<(), ()> {
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: use a custom `Error` type instead
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#result_unit_err
  = note: `#[warn(clippy::result_unit_err)]` on by default

warning: this lint expectation is unfulfilled
 --> src/main.rs:7:18
  |
7 |         #[expect(clippy::missing_panics_doc, reason = "test")]
  |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: test
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default

warning: `playground` (bin "playground") generated 3 warnings
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.51s

I expected to see this happen:
No warnings anymore.

Version

rustc 1.85.1 (4eb161250 2025-03-15)
binary: rustc
commit-hash: 4eb161250e340c8f48f66e2b929ef4a5bed7c181
commit-date: 2025-03-15
host: x86_64-unknown-linux-gnu
release: 1.85.1
LLVM version: 19.1.7

(but also reproduce-able in the playground with latest stable and nightly)

Additional Labels

No response
@hasezoey hasezoey added C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have labels Apr 3, 2025
@y21
Copy link
Member

y21 commented Apr 3, 2025

This was fixed/implemented in #14407 and was only merged 3 days ago, so the change from that PR is not on nightly yet (I think the next clippy->rust sync happens tomorrow). The lints page you linked is the state of the master branch on this repository, so it's a bit ahead of the distributed nightly clippy (which is only synced from this repo every 2 weeks).

On clippy master this no longer reproduces and the #[expect] properly silences the lint as expected.

@hasezoey
Copy link
Author

hasezoey commented Apr 3, 2025

Thanks, i didnt notice it had a version in the URL, i was linked to it by the playground and my currently installed (old stable) clippy.
Maybe it would be worth setting the version (instead of master) in the lint suggestion url? Though that would be a different issue.

@Alexendoo Alexendoo linked a pull request Apr 4, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Lint to stable/beta lint docs page in diagnostics Alexendoo/rust-clippy
2 participants
@hasezoey @y21