Format tests with rustfmt (288-299 of 299)
Extracted from #2097.
I'll make a separate PR to enable checking the `tests` directory's formatting in CI. I'll need to rebase that after both this and #2254 have landed, and if any new non-rustfmt-formatted files appear in the meantime, we can include formatting those in the same PR that enables the CI.
Format tests with rustfmt (225-275 of 300)
Extracted from #2097.
These cases all involve a line comment at the end of a block that rustfmt has chosen to wrap.
```diff
- unsafe { (*ptr).set(20); } //~ ERROR does not exist in the borrow stack
+ unsafe {
+ (*ptr).set(20);
+ } //~ ERROR does not exist in the borrow stack
```
I have moved all of those comments back onto the same line as the content of the block instead, as was indicated being `@RalfJung's` preference in https://github.com/rust-lang/miri/pull/2097#discussion_r862436672.
```diff
+ unsafe {
+ (*ptr).set(20); //~ ERROR does not exist in the borrow stack
+ }
```
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.
tweak new test suite output
- Make the entire "## Running ui tests ..." green, including the target.
- Fix double-space in `testname.rs .. ok`.
- Make the final summary a bit more like compiletest-rs, in particular the newlines around it
- Use the term "ignored" consistently, rather than "skipped"
r? `@oli-obk`
Add a command line flag to avoid printing to stdout and stderr
This is practical for tests that don't actually care about the output and thus don't want it intermingled with miri's warnings, errors or ICEs
fixes#2083
Replace unneeded use of `ref` in favor of "match ergonomics"
The signature of `check_shim` is very amenable to this.
```rust
fn check_shim<'a, const N: usize>(…) -> InterpResult<'tcx, &'a [OpTy<'tcx, Tag>; N]>
```
Instead of:
```rust
let &[ref ptr, ref flags] = this.check_shim(…)?;
```
we can write it just as:
```rust
let [ptr, flags] = this.check_shim(…)?;
```
