[regression - rust2018]: unused_mut lint false positives on nightly

[gnzlbg]

I believe this is a regression in rust2018 nightly (it wasn't triggering in earlier rust2018 builds).

---

Playground

#![deny(warnings)]  

#[allow(unreachable_code)]
pub fn sum_nan() {
    // return;

    let mut v = 0;
    assert_eq!(v, 0);
    v = 1;
    assert_eq!(v, 1);
}

fn main() {}

works correctly, but uncommenting the return; (play) errors with:

error: variable does not need to be mutable
 --> src/main.rs:7:9
  |
7 |     let mut v = 0;
  |         ----^
  |         |
  |         help: remove this `mut`

This only happens with Rust2018 on nightly (Rust2015 works fine).

[matthewjasper]

Well, the code compiles (in Rust2018) without mut, so the lint's not exactly wrong, even if the behaviour is surprising.

[gnzlbg]

@matthewjasper this is caused by the NLL feature, so maybe this is a consequence of #54943 ?

[pnkfelix]

#54943 is about well-formedness, which I don't think is part of the code that tags whether a mut was necessary or not (which is what is triggering the unused_mut warning that is then triggering the deny(warnings) you have in there.

This is an interesting scenario in terms of what one can do to mitigate this...

[gnzlbg]

@pnkfelix i've been thinking a bit about the well-formedness of unreachable code because of this. AFAICT with NLL currently unreachable code needs to be syntactically correct, to typeck and to unsafeck, but it does not need to dropck (double drops are currently allowed) or borrowck (this example).

In Rust2015 unreachable code also needs to dropck and borrowck.

[gnzlbg]

The first question that should be answered is whether these changes in the well-formedness requirements of unreachable code are by design or an accident (cc @nikomatsakis ). If this is by design, then I'd suppose they have gone through an RFC and we can close this, or leave this open with the intent of maybe adding a better warning about this.

If they are by accident, then the first thing to do is to decide what should be the correct behavior here (e.g. stick to what Rust2015 does or change that to something else?).