manual_ok_err prevents type ascription

Summary

There are some cases where a match expression provides more type information than a Result::ok call, such as when the Err arm ascribes the type. This gives the reader more information about the error being discarded. manual_ok_err should not trigger in this case.

@samueltardieu @blyxyas

Lint Name

manual_ok_err

Reproducer

I tried this code:

                let addr = match u64::from_str_radix(addr, 16) {
                    Ok(addr) => Some(addr),
                    Err(ParseIntError { .. }) => None,
                }?;

I saw this happen:

error: manual implementation of `ok`
   --> aya/src/util.rs:261:28
    |
261 |                   let addr = match u64::from_str_radix(addr, 16) {
    |  ____________________________^
262 | |                     Ok(addr) => Some(addr),
263 | |                     Err(ParseIntError { .. }) => None,
264 | |                 }?;
    | |_________________^ help: replace with: `u64::from_str_radix(addr, 16).ok()`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_ok_err

I expected to see this happen:
Nothing.

Version

rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: aarch64-apple-darwin
release: 1.84.0
LLVM version: 19.1.5

Additional Labels

No response

Start at the manual_ok_err lint entry point and reproduce the provided Rust match expression, including the Err(ParseIntError { .. }) pattern. Check how the lint compares this match with Result::ok; done means the type-ascribing case no longer emits a diagnostic while ordinary manual ok/err matches remain covered by tests.