Valiation: Identify write locks using an abstract lvalue

[RalfJung]

Fixes #296

[oli-obk]

If you want you can try using ui tests together with MIRI_LOG=rust_miri::interpret::validate=trace to be able to ensure that the trace does exactly what you want.

But I guess it would fail with an interpretation error if anything went wrong...

[RalfJung]

The test fails prior to the PR, so I think compile-fail is enough here.

[oli-obk]

❤️

[RalfJung]

Is there any way to get lints for "You used &mut but could have used &"?^^

[oli-obk]

No. But I've been trying to write a lint for that since forever: rust-lang/rust-clippy#353

[eddyb]

It should be easier on MIR because you can look for uses that aren't immutable reborrows.

[RalfJung]

I am somewhat confused by these zst2.rs and zst3.rs compile-fail tests. First of all, why were they compile-fail in the first place? They are checking that some assertion fails; might as well check that the assertion holds...

...except, it turns out, miri disagrees with rustc here. The following passes on miri, and fails on rustc:

#[derive(Debug)]
struct A;

fn main() {
    // can't use assert_eq, b/c that will try to print the pointer addresses with full MIR enabled
    assert!(&A as *const A as *const () != &() as *const _);
    assert!(&A as *const A != &A as *const A);
}

Is this a bug? Why would we deliberately test for disagreeing with rustc?

[oli-obk]

Is this a bug? Why would we deliberately test for disagreeing with rustc?

We don't deduplicate constants in all cases: #131

[RalfJung]

All right, I will then disable the test if it is buggy.