Valiation: Identify write locks using an abstract lvalue #336
Conversation
This makes a new compile-fail test pass.
| } | ||
|
|
||
| fn test(r: &mut RefCell<i32>) { | ||
| let x = &*r; // releasing write lock, first suspension recorded |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
The test fails prior to the PR, so I think compile-fail is enough here.
| @@ -1466,7 +1466,7 @@ impl<'a, 'tcx, M: Machine<'tcx>> EvalContext<'a, 'tcx, M> { | |||
|
|
|||
| /// ensures this Value is not a ByRef | |||
| pub(super) fn follow_by_ref_value( | |||
| &mut self, | |||
| &self, | |||
There was a problem hiding this comment.
Is there any way to get lints for "You used &mut but could have used &"?^^
There was a problem hiding this comment.
No. But I've been trying to write a lint for that since forever: rust-lang/rust-clippy#353
There was a problem hiding this comment.
It should be easier on MIR because you can look for uses that aren't immutable reborrows.
RalfJung
force-pushed
the
mir-validate
branch
from
ba66359 to
59a329d
Compare
|
I am somewhat confused by these ...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? |
We don't deduplicate constants in all cases: #131 |
|
All right, I will then disable the test if it is buggy. |
RalfJung
force-pushed
the
mir-validate
branch
from
5699376 to
1c96472
Compare
RalfJung
force-pushed
the
mir-validate
branch
from
1c96472 to
5d2ed4d
Compare
Fixes #296