MIR-borrowck: add "consider changing this to `mut x`" note, as in AST borrowck

[arielb1]

Currently, when you try to access an immutable local, AST borrowck suggests that you should change it to mut x, for example:

fn main() {
    let x = 0;
    x = 1;
    std::mem::replace(&mut x, 2);
}

warning: value assigned to `x` is never read
 --> src/main.rs:2:9
  |
2 |     let x = 0;
  |         ^
  |
  = note: #[warn(unused_assignments)] on by default

error[E0596]: cannot borrow immutable local variable `x` as mutable
 --> src/main.rs:4:28
  |
2 |     let x = 0;
  |         - consider changing this to `mut x` <---- THIS NOTE
3 |     x = 1;
4 |     std::mem::replace(&mut x, 2);
  |                            ^ cannot borrow mutably

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:3:5
  |
2 |     let x = 0;
  |         - first assignment to `x`
3 |     x = 1;
  |     ^^^^^ cannot assign twice to immutable variable

error: aborting due to 2 previous errors

MIR borrowck should be doing this too.

FIXME: I should write mentor notes

[arielb1]

Note: this is somewhat lower priority than the rest of the NLL work.

How to implement this

The AST borrow-checker has mutability blaming code in the following place:

rust/src/librustc_borrowck/borrowck/mod.rs

Line 1193 in f28df20

fn note_immutability_blame(&self,

That code needs to be ported to MIR borrowck. The code uses the immutability_blame function on mem_categorization, which needs to be ported to work on MIR lvalues instead of cmt, which I don't think should be a problem.

The AST borrowck looks up data on user local variables using the local's NodeId in order to make this error report. Therefore, it might probably a good idea to change the is_user_variable field of mir::LocalDecl to an Option<ast::NodeId> and store the user local's NodeId in order to look up that information (or there might be a different way of doing this) - https://github.com/rust-lang/rust/blob/f28df200260c89b2a0bdf942510e0f888c29a70d/src/librustc/mir/mod.rs#L440-485

[raventid]

I'd like to take this one. I already took #46186(at least I wrote i'd like to :) ), they touch different parts of diagnostic system(as far as I can see now), so I'd like to solve both to get a taste of what's going on from different angles.

[arielb1]

@raventid

Cool! If you have any questions, feel free to ping me on WG-compiler-nll or WG-compiler-errors on gitter.

[nikomatsakis]

@raventid I'm guessing you never found time to do this, right? (No worries, just checking in.)

[raventid]

@nikomatsakis, yep. To be frank - I even forgot I started this. I actually had some time to tweak this a bit, but it happend to be a bit harder then I expected, I didn't manage to find a way to easily port immutability_blame to MIR vals. I'm still interested in taking this :) I can make some progress in next couple of weeks + some time to accept PR + fix review notes = I can make it real in 3 weeks. If it sounds like an acceptable deadline - you can count on me, if not, well, I'll try something else later.

[nikomatsakis]

@spastorino is gonna take a crack at this I think