Skip field retagging on ZSTs, it can take forever
I just tried running the `alloc`'s tests with `miri-test-libstd` with field retagging enabled. The test suite eventually hangs on a few tests which pass around ZSTs that have a lot of fields.
I don't really know how to test this effectively. The test passes, but if you remove this fast-path it effectively just hangs the interpreter. And since it hangs _inside_ a step, there's no hope for doing some kind of timeout within the test.
slightly improve protector-related error messages
I find the current retag messages confusing, since they sound like the item *was* protected, when it still actively *is* protected (and that is, in fact, the issue).
Example error message:
```
error: Undefined Behavior: not granting access to tag <3095> because incompatible item [Unique for <3099>] is protected by call 943
--> tests/fail/stacked_borrows/invalidate_against_barrier1.rs:5:25
|
5 | let _val = unsafe { *x }; //~ ERROR: protect
| ^^ not granting access to tag <3095> because incompatible item [Unique for <3099>] is protected by call 943
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <3095> was created by a SharedReadWrite retag at offsets [0x0..0x4]
--> tests/fail/stacked_borrows/invalidate_against_barrier1.rs:10:16
|
10 | let xraw = &mut x as *mut _;
| ^^^^^^
help: <3095> cannot be used for memory access because that would remove protected tag <3099>, protected by this function call
--> tests/fail/stacked_borrows/invalidate_against_barrier1.rs:1:1
|
1 | / fn inner(x: *mut i32, _y: &mut i32) {
2 | | // If `x` and `y` alias, retagging is fine with this... but we really
3 | | // shouldn't be allowed to use `x` at all because `y` was assumed to be
4 | | // unique for the duration of this call.
5 | | let _val = unsafe { *x }; //~ ERROR: protect
6 | | }
| |_^
help: <3099> was derived from <3098>, which in turn was created here
--> tests/fail/stacked_borrows/invalidate_against_barrier1.rs:12:17
|
12 | inner(xraw, xref);
| ^^^^
= note: backtrace:
= note: inside `inner` at tests/fail/stacked_borrows/invalidate_against_barrier1.rs:5:25
note: inside `main` at tests/fail/stacked_borrows/invalidate_against_barrier1.rs:12:5
--> tests/fail/stacked_borrows/invalidate_against_barrier1.rs:12:5
|
12 | inner(xraw, xref);
| ^^^^^^^^^^^^^^^^^
```
r? `@saethlin`
Strengthen C++20 SC accesses
`@SabrinaJewson` noted in #2301 that Miri could produce behaviours forbidden under C++20 even without SC fences. Due to the added coherence-ordered before relationship which is created from read from and read before, plus the fact that coherence-ordered before between SC operations must be consistent with the Global Total Order S, in C++20 if there's an SC load that reads from any store, then a later SC load cannot read before that store. This PR adds this restriction
Use ui_test from crates.io instead of having it in-tree
I have moved a copy of the `ui_test` crate into [a separate repo](https://github.com/oli-obk/ui_test) to facilitate the further non-miri development of it. I will keep syncing until we have reached a point where we don't touch it anymore for miri. At that point we can remove the in-tree version and do further development out of tree.
Run `pass` tests without building dependencies first
fixes https://github.com/rust-lang/miri/issues/2442
One thing that I'm wondering is if we should do away with running each folder individually and make `ui_test` support running all tests in parallel (so building deps becomes a thread, and all tests needing deps are blocked on it)
move vector_clock and sync into concurrency & make vector_clock private
Closes https://github.com/rust-lang/miri/issues/2199
The thread.rs didn't have to be moved to build.
If it makes more sense to move the thread.rs as well, please let me know. I can move it as well.
add ./miri cargo for RA to invoke
RA expects a check command to check *individual workspaces*, whereas `./miri` is designed to check/build/test all parts of Miri. So add a new `./miri cargo` that performs just a single cargo invocation, but with the right env vars so that the build cache can be shared with `./miri check`.
