Lint dangerous uses of shadowing

We have three shadowing lints

• shadow reuse
  • detect let x = consuming_operation(x);
• shadow same
  • detect let x = &x;
• shadow unrelated
  • detect let x = ...; let x = y;

which all try to address shadowing issues. Unfortunately enabling either of these lints will also lint idiomatic and readable code. We should find a way to write a lint that only detects actually problematic cases of shadowing.

All of the cases below are even more prominent if you include mutable bindings, as it becomes very hard to distinguish which variable is changed by a x = ... statement.

Shadowing in a small scope

let x = foo;
....
{
    let x = bar;
    ...
    use(x);
    use1(x);
}
use2(x); // at this point we see the `use1(x)` above and
// may assume these two `x` are related

Shadowing in match arm patterns

https://github.com/rust-lang-nursery/rust-clippy/issues/2890

let x = foo;
...
match bar {
    Some(x) => use(x),
    None => use(x),
}

Shadowing in conditional early aborts

probably not as problematic as the first case mentioned, but would get caught by a naive implementation of the first case.

let x = foo;
....
if meh {
    let x = bar;
    ...
    use(x);
    use1(x);
    return;
}
use2(x); // at this point we see the `use1(x)` above and
// may assume these two `x` are related

Start by reviewing the existing shadow_reuse, shadow_same, and shadow_unrelated lints and the linked issue about shadowing in match arm patterns. Compare the listed scope, pattern, and early-abort examples with the cases those lints currently report. Done means defining and implementing a lint that catches genuinely problematic shadowing without flagging idiomatic, readable code.