Format tests with rustfmt (151-200 of 300)
Extracted from #2097.
This PR is still only doing the easy cases with no comments involved.
In the next PRs after this, I'll start grouping by common comment patterns, e.g. all the cases resembling https://github.com/rust-lang/miri/pull/2097#discussion_r862436672 together in one PR.
Format tests with rustfmt (51-100 of 300)
Extracted from #2097.
Like #2244, this is intended to be "easy" cases which don't involve comments in the vicinity.
Five of the files being skipped here are because rustfmt is buggy (see
the error messages below). The others have clearly preferable manual
formatting.
error[internal]: left behind trailing whitespace
--> tests/fail/validity/transmute_through_ptr.rs:18:18:1
|
18 |
| ^^^^
|
warning: rustfmt has failed to format. See previous 1 errors.
error[internal]: left behind trailing whitespace
--> tests/fail/stacked_borrows/illegal_read2.rs:10:10:1
|
10 |
| ^^^^
|
warning: rustfmt has failed to format. See previous 1 errors.
error[internal]: left behind trailing whitespace
--> tests/fail/stacked_borrows/illegal_read5.rs:15:15:1
|
15 |
| ^^^^
|
warning: rustfmt has failed to format. See previous 1 errors.
error[internal]: left behind trailing whitespace
--> tests/fail/stacked_borrows/illegal_read1.rs:10:10:1
|
10 |
| ^^^^
|
warning: rustfmt has failed to format. See previous 1 errors.
error[internal]: left behind trailing whitespace
--> tests/fail/erroneous_const2.rs:9:9:1
|
9 |
| ^^^^
|
warning: rustfmt has failed to format. See previous 1 errors.
Prevent futex_wait from actually waiting if a concurrent waker was executed before us
Fixes#2223
Two SC fences were placed in `futex_wake` (after the caller has changed `addr`), and in `futex_wait` (before we read `addr`). This guarantees that `futex_wait` sees the value written to `addr` before the last `futex_wake` call, should one exists, and avoid going into sleep with no one else to wake us up.
ada7b72a87/src/concurrency/weak_memory.rs (L324-L326)
Earlier I proposed to use `fetch_add(0)` to read the latest value in MO, though this isn't the proper way to do it and breaks aliasing: syscall caller may pass in a `*const` from a `&` and Miri complains about write to a `SharedReadOnly` location, causing this test to fail.
ada7b72a87/tests/pass/concurrency/linux-futex.rs (L56-L68)
test ui output also in rustc test suite
`@oli-obk` when I just tried this locally (`./x.py test src/tools/miri --stage 0`), it worked fine. What differences had you seen before?
make Miri's scheduler proper round-robin
When thread N blocks or yields, we activate thread N+1 next, rather than always activating thread 0. This should guarantee that as long as all threads regularly yield, each thread eventually takes a step again.
Fixes the "multiple loops that yield playing ping-pong" part of https://github.com/rust-lang/miri/issues/1388.
`@cbeuw` I hope this doesn't screw up the scheduler-dependent tests you are adding in your PR.
ui_test tweaks
- support multiple filters
- make `./miri check` also cover ui_test
- Run opt-level=4 tests again, but only the "run" tests
r? `@oli-obk`
Save a created event for zero-size reborrows
Currently, we don't save a created event for zero-sized reborrows. Attempting to use something from a zero-sized reborrow is surprisingly common, for example on `minimal-lexical==0.2.1` we previously just emit this:
```
Undefined Behavior: attempting a write access using <187021> at alloc72933[0x0], but that tag does not exist in the borrow stack for this location
--> /root/rust/library/core/src/ptr/mod.rs:1287:9
|
1287 | copy_nonoverlapping(&src as *const T, dst, 1);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| attempting a write access using <187021> at alloc72933[0x0], but that tag does not exist in the borrow stack for this location
| this error occurs as part of an access at alloc72933[0x0..0x8]
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the 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
= note: inside `std::ptr::write::<u64>` at /root/rust/library/core/src/ptr/mod.rs:1287:9
note: inside `minimal_lexical::stackvec::StackVec::push_unchecked` at /root/build/src/stackvec.rs:82:13
--> /root/build/src/stackvec.rs:82:13
|
82 | ptr::write(self.as_mut_ptr().add(self.len()), value);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... backtrace continues...
```
Which leaves us with the question "where did we make this pointer?" because for every other diagnostic you get a "was created by" note, so I suspect people might be tempted to think there is a Miri bug here. I certainly was.
---
This code duplication is so awful, I'm going to take a look at cleaning it up later. The fact that `ptr_get_alloc_id` can fail in this situation makes things annoying.
Add support for _COARSE clocks
Original idea does not work, so I'm just going to try expanding support to include the `_COARSE` clocks.
The original motivation for this PR is that the test suite for the crate [`minstant`](https://crates.io/crates/minstant) reports UB, because it tries to use a clock type Miri didn't support, but never checked for an error code and so just used the uninit `libc::timespec`. So, that's technically a bug in `minstant`, but outside of Miri you'd have to be using an incredibly old Linux to ever see an `EINVAL` so the more helpful thing for Miri to do is behave like a newer Linux.
So now we don't detect UB in `minstant`, but we have a test failure:
```
failures:
---- src/instant.rs - instant::Instant::as_unix_nanos (line 150) stdout ----
Test executable failed (exit status: 101).
stderr:
thread 'main' panicked at 'assertion failed: (instant.as_unix_nanos(&anchor) as i64 - expected as i64).abs() < 1_000_000', src/instant.rs:11:1
```
I'm having trouble getting my head around the code in `minstant` that's involved in this test, but as far as I can tell from the man pages, these `_COARSE` clocks meet the requirements.
Closes https://github.com/rust-lang/miri/issues/1983 at least as best as I can.
