`unused_variables` and `unused_assignments` lints do not catch array usage

[jamesmunns]

I recently had a problem where I was accidentally implicitly copying an array with if let bindings, and the writes to the original array were never made (I needed to add ref in my bindings). I thought it was strange that there was no warnings for this, and noticed this is true for these lints in general. Here's a small reproduction (also on the playground).

fn main() {
    // Write but never read. No warning is emitted
    let mut arr = [0; 5];
    arr[0] = 4;
    [0][0] = 0;
    
    // Write but never read, the following warnings are emitted
    
    // warning: variable `x` is assigned to, but never used
    //  --> src/main.rs:7:13
    //   |
    // 7 |     let mut x = 4;
    //   |             ^
    //   |
    //   = note: `#[warn(unused_variables)]` on by default
    //   = note: consider using `_x` instead
    
    // warning: value assigned to `x` is never read
    //  --> src/main.rs:8:5
    //   |
    // 8 |     x = 12;
    //   |     ^
    //   |
    //   = note: `#[warn(unused_assignments)]` on by default
    //   = help: maybe it is overwritten before being read?
    let mut x = 4;
    x = 12;
}

I would expect these lints to fire here, is this expected behavior? I tried a quick search and wasn't able to find an existing issue.

[Centril]

Adding T-Lang for the "do we want to do this" aspect of the lint beyond it's execution (T-Compiler).

I would expect these lints to fire here, is this expected behavior?

The current behavior is expected. These lints are defined through a liveness analysis done on HIR rather than MIR and understanding arrays specially on HIR might not be worth the impl complexity.

[Centril]

However, @eddyb suggested that we rewrite liveness to work on MIR instead and then we should be able to make this work and then some. Cc @nikomatsakis @matthewjasper @tmandry

[estebank]

If we extend rustc to detect this case it would be the same machinery necessary to support #58792, either to suggest split_at_mut or to make it unnecessary by keeping track of non-overlapping mutable borrows during borrowck.

[nikomatsakis]

My opinion is that it would be good to detect cases like this -- probably we could say that any write to the 'owned content' of a variable suffices. I agree it'd probably be somewhat easier to do this sort of thing on MIR -- certainly I consider the existing 'liveness' code to be in need of a rewrite.

There are some questions as to how smart we want to be. One could imagine for example warning on a case like this

let mut foo =(0, 0);
foo.0 = 22;
println!("{}", foo.1);

Here, the write to foo.0 is dead.

[Centril]

Here, the write to foo.0 is dead.

It seems to me that declaring foo.0 dead in the lint here is more conservative than doing so for arrays so if we accept @jamesmunns's idea we ought to declare foo.0 dead as well.
We could also divide the aggressiveness into different lints (still same machinery, just different names for the lints.)

[pacak]

More examples, here neither q nor foo are read back.

#[derive(Copy, Clone)]
pub struct Foo {
    pub foo: usize,
}

pub fn foo(src: Foo) {
    let mut q = src;
    q.foo = 12;
}

    let mut foo = (0, 0);                                                                  
    foo.0 = 22;      

[camsteffen]

I've linked a couple Clippy issues to this, for more examples.

Also it might be good to detect unused Futures in a similar way, as in rust-lang/rust-clippy#8126.