[missing_panics_doc] doesn't trigger on expect

[wookietreiber]

Summary

Doesn't trigger on expect. Noticed when changing from unwrap to expect to provide a better message, and the lint was suddenly gone.

Lint Name

missing_panics_doc

Reproducer

I tried this code:

#[deny(clippy::missing_panics_doc)]

pub fn last_unwrap(v: &[u32]) -> u32 {
    *v.last().unwrap()
}

pub fn last_expect(v: &[u32]) -> u32 {
    *v.last().expect("passed an empty thing")
}

I expected to see this happen: issue error for both last_unwrap and last_expect.

Instead, this happened:

Version

rustc 1.67.0 (fc594f156 2023-01-24)
binary: rustc
commit-hash: fc594f15669680fa70d255faec3ca3fb507c3405
commit-date: 2023-01-24
host: x86_64-unknown-linux-gnu
release: 1.67.0
LLVM version: 15.0.6

[wookietreiber]

I wanted to extend the example a bit to include expect for both Option and Result:

#[deny(clippy::missing_panics_doc)]

pub fn option_unwrap<T>(v: &[T]) -> &T {
    let o: Option<&T> = v.last();
    o.unwrap()
}

pub fn option_expect<T>(v: &[T]) -> &T {
    let o: Option<&T> = v.last();
    o.expect("passed an empty thing")
}

pub fn result_unwrap<T>(v: &[T]) -> &T {
    let res: Result<&T, &str> = v.last().ok_or("oh noes");
    res.unwrap()
}

pub fn result_expect<T>(v: &[T]) -> &T {
    let res: Result<&T, &str> = v.last().ok_or("oh noes");
    res.expect("passed an empty thing")
}

Which only yields an error for the Option::unwrap case, neither of the other ones:

I also made the examples generic in types and the types explicit.

---

Let me know if I should make a new issue for not triggering on Result::unwrap.

[KisaragiEffective]

@rustbot claim

[vilgotf]

I think this should be reverted as it contradicts the recommendation for how expect should be used

Recommended Message Style
We recommend that expect messages are used to describe the reason you expect the Option should be Some.

I always use expect like an inline unreachable! so with this change I either have to ignore this lint, switch to a verbose match statement with an unreachable! branch, or leak internal invariants.

[Alexendoo]

I don't see a contradiction there, to me that's solely about the wording of the message. As an example slice::windows uses expect for a public facing panic

See #11436 though for a potential way to configure this