CopyProp miscompilation when destination is borrowed

[tmiasko]

fn main() {
    let mut a;
    let mut b;
    let mut c;
    let     d = false;
    let mut p = &raw const d;
    loop {
        a = !unsafe { *p };
        b = !unsafe { *p };
        c = a;
        p = &c as *const _;
        assert_eq!({a}, {b});
    }
}

$ rustc a.rs -Cdebug-assertions=off -Zmir-opt-level=0 && ./a
# Program terminated manually. OK.
$ rustc a.rs -Cdebug-assertions=off && ./a

thread 'main' panicked at a.rs:12:9:
assertion `left == right` failed
  left: false
 right: true
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[theemathas]

Also reproduces without unsafe

fn main() {
    let mut c;
    let mut p = &false;
    loop {
        let a = !*p;
        let b = !*p;
        c = a;
        p = &c;
        assert_eq!({a}, {b});
    }
}

Reproduces on 1.89.0-beta.3

@rustbot label +regression-from-stable-to-beta

[lqd]

This is probably from #142571 cc @cjgillot

[tmiasko]

Consider copy propagation from x to y in the following MIR fragment, before:

  x = copy (*p);
  z = copy (*q);
  y = copy x;
  ...
  // Optionally: p = &y
  // Optionally: q = &y

After:

  x = copy (*p);
  z = copy (*q);
  ...
  // Optionally: p = &x
  // Optionally: q = &x

Currently copy propagation is performed when y is borrowed (when borrows grants read access only). This is incorrect when p points to y, since it introduces an overlapping assignment in x = copy (*p). Furthermore, when q points to y, then it changes value assigned in z = copy (*q).

The root problem is in the assumption that for a borrowed local, all uses of it are dominated by the defining assignment.

In the example, I think we should reject copy propagation when y is borrowed. On the other hand, I don't see any issue with x being borrowed. It seems fine to introduce additional reads from x in locations dominated by the definition of x.