clarifying comments for target-dir handling
I thought we could simplify this logic, but alas, `cargo metadata --target-dir` is not a thing (even though the effective target-dir *does* affect the metadata).
fix RUSTC_BACKTRACE always being set
I kept wondering why Miri programs, whenever isolation is disabled, behave as if RUSTC_BACKTRACE was set. Finally I realized it's because some early rustc setup code sets that env var, and that is then propagated to the interpreted program.
So fix that by taking a copy of the environment before any rustc setup, and use that copy as the basis for what is provided to the interpreted program.
implement some missing float functions
With this we support the entire float API surface of the standard library. :)
Also fixes https://github.com/rust-lang/miri/issues/2468 by using host floats to implement FMA.
avoid strerror_r failure on unknown errnum
This is an informative function anyway, so as fallback just return a string with the raw errnum. Avoids panics / interpreter aborts in std on unknown errnum in from_raw_os_error.
Add additional raw error mappings for the nightly `io_error_more` feature
Some crates are using nightly and failing when mapping these errors,
for example <https://miri.saethlin.dev/?crate=remove_dir_all&version=0.7.0>:
```
error: unsupported operation: io error NotADirectory cannot be translated into a raw os error
--> /root/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/sys/unix/fs.rs:1203:19
```
Some crates are using nightly and failing when mapping these errors,
for example <https://miri.saethlin.dev/?crate=remove_dir_all&version=0.7.0>:
```
error: unsupported operation: io error NotADirectory cannot be translated into a raw os error
--> /root/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/sys/unix/fs.rs:1203:19
```
Use cargo_metadata in cargo-miri
Closes#2393
Added `cargo_metadata` to `cargo-miri` and changed metadata from manual parsing to `cargo_metadata` invocations. Thus, removed local `Metadata` struct too.
Happy to fix if anything isn't right :)
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.
