bors [Sun, 5 Jun 2022 18:37:07 +0000 (18:37 +0000)]
Auto merge of #2197 - RalfJung:round-robin, r=RalfJung
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.
bors [Sun, 5 Jun 2022 15:18:39 +0000 (15:18 +0000)]
Auto merge of #2189 - RalfJung:clippy, r=RalfJung
run Clippy on CI
and fix some things it complains about. Also use `rustup-toolchain` script on CI (reduces code duplication, and good thing to make sure it keeps working, since we recommend it in the docs).
I left `ui_test` out for now; I'll leave those nits to `@oli-obk.` ;)
bors [Wed, 1 Jun 2022 13:01:22 +0000 (13:01 +0000)]
Auto merge of #2174 - RalfJung:summary, r=oli-obk
print list of failed tests in summary
compiletest does this and it is quite useful; see e.g. [here](https://github.com/rust-lang/rust/runs/6473917188?check_suite_focus=true). Example output:
bors [Wed, 1 Jun 2022 07:22:31 +0000 (07:22 +0000)]
Auto merge of #2173 - RalfJung:rustlib, r=oli-obk
different strategy for normalizing Rust stdlib path
`-Zremap-cwd-prefix` has some [unintended side-effects](https://github.com/rust-lang/miri/issues/2172), so we could use regexp-based normalization instead. Unfortunately, this will fail if the user's home directory contains a space.
bors [Mon, 30 May 2022 23:43:51 +0000 (23:43 +0000)]
Auto merge of #2145 - saethlin:zero-size-creation, r=RalfJung
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.
bors [Mon, 30 May 2022 21:41:41 +0000 (21:41 +0000)]
Auto merge of #2165 - saethlin:more-clocks, r=RalfJung
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:
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.
bors [Wed, 25 May 2022 17:39:53 +0000 (17:39 +0000)]
Auto merge of #2157 - RalfJung:tests, r=oli-obk
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"
bors [Wed, 25 May 2022 14:35:06 +0000 (14:35 +0000)]
Auto merge of #2151 - RalfJung:numbers, r=oli-obk
enable number validity checking and ptr::invalid checking by default
This removes the `-Zmiri-check-number-validity` flag, enabling its effects by default. (We don't error when the flag is passed, for backwards compatibility.) We also enable by default that transmuting an integer to a pointer now creates a pointer with `None` provenance, which is invalid to dereference (and, in the case of a function pointer, invalid to call). I did this together since it is all related to ptr2int/int2ptr transmutation.
Two new flags are added to optionally take back these stricter checks:
- `-Zmiri-allow-uninit-numbers` makes Miri accept uninit data in integers and floats
- `-Zmiri-allow-ptr-int-transmute` makes Miri accept pointers (provenance data) in integers and floats, *and* makes Miri treat int2ptr transmutes as equivalent to a cast.
The flag names make sense IMO, but they are somewhat inconsistent with our existing flags since we usually call things `-Zmiri-disable-$CHECK` rather than `-Zmiri-allow-$THING`. But `-Zmiri-disable-uninit-number-check` sounds silly?
(Whenever I say "transmute" this includes union and pointer based type punning.)
Cc `@saethlin` I hope this won't break everything?^^ I think the most risky part is the int2ptr transmute aspect, in particular around function pointers where no `as` casts are possible. The correct pattern is to first cast to a raw ptr and then transmute that to a fn ptr. We should probably document this better, in the `transmute` documentation and maybe in the documentation for the `fn()` type. I should run this PR against the std test suite before we land it.
r? `@oli-obk`
- [x] Ensure stdlib docs recommend "usize -> raw ptr -> fn ptr" for int-to-fnptr casts: https://github.com/rust-lang/rust/pull/97321
- [x] Run the stdlib test suite
bors [Tue, 24 May 2022 15:17:33 +0000 (15:17 +0000)]
Auto merge of #2138 - JakobDegen:call-fallout, r=RalfJung
Adjust Miri to also require return places everywhere
This is the miri side of rust-lang/rust#96098 . It'll still need a bump to rust-version once the rust PR is merged, but the test suite passes against my local build of rustc.
projects / rust.git / log