shadow_unrelated seems to get confused in nested maps

[mpalmer]

Summary

When I use the same variable name inside a closure passed to Option.map as the variable is named, shadow_unrelated fires, which is odd because this is pretty much the definition of "uses the original value".

Lint Name

shadow_unrelated

Reproducer

I tried this code:

#![deny(clippy::shadow_unrelated)]                                                                                                                                                                                                             
                                                                                                                                                                                                                                               
fn main() {                                                                                                                                                                                                                                    
    let a: Vec<Option<u8>> = [100u8, 120, 140]                                                                                                                                                                                                 
        .iter()                                                                                                                                                                                                                                
        .map(|i| i.checked_mul(2))                                                                                                                                                                                                             
        .map(|i| i.map(|i| i - 10))                                                                                                                                                                                                            
        .collect();                                                                                                                                                                                                                            
    println!("{a:?}");                                                                                                                                                                                                                         
}                                                                                                                                                                                                                                              

I saw this happen:

    Checking shadow_test v0.1.0 (/tmp/shadow_test)
error: `i` shadows a previous, unrelated binding
 --> src/main.rs:7:25
  |
7 |         .map(|i| i.map(|i| i - 10))
  |                         ^
  |
note: previous binding is here
 --> src/main.rs:7:15
  |
7 |         .map(|i| i.map(|i| i - 10))
  |               ^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#shadow_unrelated
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(clippy::shadow_unrelated)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `shadow_test` due to previous error

I expected to see this happen:

Clippy does not report a problem.

Version

rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-unknown-linux-gnu
release: 1.69.0
LLVM version: 15.0.7

(Same problem occurs with current nightly, `cargo 1.71.0-nightly (13413c64f 2023-05-10)`)

Additional Labels

No response

[kpreid]

I was just trying out shadow_unrelated and got a lot of reports for other functions taking closures. Perhaps it would be useful to generally permit, for any function call, f(x, |x| {...}) — a shadowing binding in a closure parameter list that shadows a variable used directly in the enclosing function call arguments.