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.
Avoid error patterns matching themselves
fixes#2156
fixes https://github.com/rust-lang/miri/issues/2155
this will be obsolete the moment I extract that data from json diagnostics instead of just regexing the stderr.
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`
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
Move test suite to ui tests and bless stderr output
fixes#2027
* [ ] //~ annotations should check that the error happens on their line
* [x] document all the things
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.
Rustup
In particular, this contains https://github.com/rust-lang/rust/pull/97219. Miri support for actually erroring on misuse of `ptr::invalid` will happen later.
Also move some more tests to better locations.
split flag section into common and advanced flags
As discussed with `@oli-obk` . However I was not always sure which flags to put where, so if you think some flags should be in the other category please let me know. :)
