Use real exec on cfg(unix) targets
Closes https://github.com/rust-lang/miri/issues/2421
The standard library has a platform extension trait that lets us get the behavior we want on cfg(unix), so why not use it?
I tried this out and it produces the correct behavior in concert with nextest.
When cargo-miri is executed as a cargo test runner or rustdoc runtool,
external tools expect what they launch as the runner/runtool to be the
process actually running the test. But in the implementation, we launch
the Miri interpreter as a subprocess using std::process::Command. This
tends to confuse other tools (like nextest) and users (like the author).
What we really want is to call POSIX exec so that the cargo-miri process
becomes the interpreter.
So this implements just that; we call execve via a cfg(unix) extension
trait. Windows has no such mechanism, but it also doesn't have POSIX
signals, which is the primary tripping hazard this change fixes.
fix build.rs invoking RUSTC to do check builds
This makes the Miri driver, when invokved via the RUSTC env var from inside a build script, behave almost entirely like rustc. I had to redo how we propagate sysroot information for this (which is actually back to how we used to do sysroot propagation many years ago).
Fixes https://github.com/rust-lang/miri/issues/2431
this requires a change in sysroot handling: miri driver now requires
MIRI_SYSROOT to be set when it is in 'target' mode, rather than relying on
`--sysroot` always being present.
cargo-miri: use '--config target.runner' rather than the TARGET_RUNNER env vars
That means we can properly escape spaces in our filename. This should fix https://github.com/rust-lang/miri/issues/2417, hopefully for real this time. We can also specify a "leading command" which makes it much easier to disambiguate runner invocations from rustdoc invocations!
Thanks to `@ehuss` for suggesting this.
don't dump xargo output onto users of 'cargo miri test'
The xargo invocation prints a lot of details users probably won't care about, so let's hide them (unless the user did `cargo miri setup`, then we still print everything).
add a flag to print a diagnostic when an outdated value is returned from an atomic load
Helps with https://github.com/rust-lang/miri/issues/2313. It can still be annoying to figure out *which* outdated load is the important one in case there are many of them (and the issue contains some ideas for how to help with that situation), but having this flag is better than nothing.
Thanks to `@cbeuw` for the [original patch](64d738cb00) that I based this on.
support MIRI_HOST_SYSROOT env var for stage 0 builds
Together with a [patch on the rustc side](https://github.com/rust-lang/rust/pull/99599), this makes `./x.py test src/tools/miri --stage 0` work again. :)
r? `@oli-obk`
