shadow_unrelated breaks when intermediary bindings are used

[gnzlbg]

Playground:

pub fn foo(a: i32) {
    let b = 3 * (3 + 1) / 2;
    let c = (f64::from(a) / f64::from(b)) as i32;

    let a = c + b;

    let _ = a;
}

produces

error: `a` is shadowed by `c + b`
 --> src/main.rs:8:9
  |
8 |     let a = c + b;
  |         ^
  |
note: lint level defined here
 --> src/main.rs:2:44
  |
2 | #![cfg_attr(feature = "cargo-clippy", deny(clippy::shadow_unrelated))]
  |                                            ^^^^^^^^^^^^^^^^^^^^^^^^
note: initialization happens here
 --> src/main.rs:8:13
  |
8 |     let a = c + b;
  |             ^^^^^
note: previous binding is here
 --> src/main.rs:4:12
  |
4 | pub fn foo(a: i32) {

The lint incorrectly errors that the new binding a is unrelated to the function argument a, but this is incorrect since these two bindings are related via c.

[detly]

Another example involving iterators:

fn decode() -> Option<Vec<u8>> {
    let message = b"prefix_message_goes_here";
    let mut iter = message.splitn(2, |&byte| byte == b'_');
    let prefix = iter.next()?;
    let message = iter.next()?;
    todo!()
}

[kpreid]

I just hit this kind of case with an into_inner():

#![warn(clippy::shadow_unrelated)]

use std::io::BufWriter;
use std::fs::File;

pub fn example(file: File) {
    let writer = BufWriter::new(file);
    // writer.write...
    let file = writer.into_inner().unwrap(); // warning: `file` shadows a previous, unrelated binding
    file.sync_all().unwrap();
}

(The above code could be rewritten with BufWriter::new(&mut file), but let’s suppose we have some reason not to do that, like needing to pass 'static data to threads/tasks.)

However, I'm not sure there's any general way to prevent this type of false positive without also creating many false negatives, due to actually-“unrelated” bindings happening to depend indirectly on data from the shadowed binding, but not in a way that justifies a shadowing. When I came here to file an issue, I was thinking that wrapping and unwrapping via functions named into_inner() deserved special recognition.

Another possibility would be not warning when the original variable is moved out of (as file is here), but that’s of debatable semantic significance, and would not help with either of the previously posted examples since they involve Copy types.