Add support for panicking in the emulated application when unsupported functionality is encountered
This PR fixes#1807 and allows an optional flag to be specified to panic when an unsupported syscall is encountered. In essence, instead of bubbling up an error in the context of the Miri application Miri will panic within the context of the *emulated* application. This feature is desired to allow CI pipelines to determine if a Miri failure is unsupported functionality or actual UB. Please read [this comment](https://github.com/rust-lang/miri/issues/1807#issuecomment-845425076) for the rationale behind this change.
Note: this change does not cover all cases where unsupported functionality errors may be raised. If you search the repo for `throw_unsup_format!` there are many cases that I think are less likely to occur and may still be problematic for some folks.
TODO:
- [x] README documentation on this new flag
- [x] Add tests
In user interface, added a new flag `-Zmiri-isolation-error` which
takes one of the four values -- hide, warn, warn-nobacktrace, and
abort. This option can be used to configure Miri to either abort or
return an error code upon executing isolated op. If not aborted, Miri
prints a warning, whose verbosity can be configured using this flag.
In implementation, added a new enum `IsolatedOp` to capture all the
settings related to ops requiring communication with the
host. Old `communicate` flag in both miri configs and machine
stats is replaced with a new helper function `communicate()` which
checks `isolated_op` internally.
Added a new helper function `reject_in_isolation` which can be called
by shims to reject ops according to the reject_with settings. Use miri
specific diagnostics function `report_msg` to print backtrace in the
warning. Update it to take an enum value instead of a bool, indicating
the level of diagnostics.
Updated shims related to current dir to use the new APIs. Added a new
test for current dir ops in isolation without halting machine.
Rustc removed the target wrapper and exposed the target directly.
Result of running:
find . -type f -exec sed -i -e 's/target\.target\([)\.,;]\)/target\1/g' {} \;
Plus one manual edit of the rust-version file
1. Fix 'fn convert_path_separator' in src/shims/os_str.rs
2. Fix 'fn set_last_error_from_io_error' in src/helpers.rs
3. Minor comment fix for 'fn SetCurrentDirectoryW' in src/shims/env.rs
move OsStr helpers to a separate file
Moved OsStr read/write functions from `src/helpers.rs` to `src/shims/os_str.rs`, in order to keep `src/helpers.rs` from bloating too much.
Add statx shim for linux target
This is an attempt to fix: https://github.com/rust-lang/miri/issues/999 (for linux only)
Currently there is one problem that I haven't been able to solve. `std::fs::metadata` fails because the creation time is not available even though it is provided in the shim code.
In order to inform the caller that the field was provided, the `stx_flag` field must have the bits of `STATX_BTIME` set (which they are). The creation time is in the `stx_btime` field of the `statx` struct (see [1]). The relevant code in `libstd` is here (probably?): https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/fs.rs#L322
Another important point is that we are just providing the fields that are available in "all" platforms (this is, without using any platform specific traits or so). This can be improved later.
References:
[1] Man page: http://man7.org/linux/man-pages/man2/statx.2.html
[2] libc `statx` struct: https://docs.rs/libc/0.2.63/libc/struct.statx.html
Edit: The problem is that my filesystem is not providing it and I thought all filesystems could provide it. I changed the code so it only provides those dates if they are available. now we are ready to go.
r? @RalfJung @oli-obk
