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.
Add random failures to compare_exchange_weak
In practice this is pretty useful for detecting bugs.
This fails more frequently than realistic (~~50%~~ (now 80%, controlled by a flag) of the time). I couldn't find any existing code that tries to model this (tsan, cdschecker, etc all seem to have TODOs there). Relacy models it with a 25% or 50% failure chance depending on some settings.
CC `@JCTyblaidd` who wrote the code this modifies initially, and seems interested in this subject.
Weaken release sequences to match the C++20 memory model
See [Weaken Release Sequences](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0982r1.html), since the exception for relaxed writes on the same thread as a release write not blocking release sequences was removed in the C++20 memory model compared to the C11 memory model the paper was based on. The implementation can be updated and simplified to match this. [Rust is currently specified to use the C++20 memory model](https://doc.rust-lang.org/std/sync/atomic/index.html).
Add simple data-race detector
Partially fixes data-race detection, see #1372, based on Dynamic Race Detection for C++11
- This does not explore weak memory behaviour, only exploring one sequentially consistent ordering.
- Data-race detection is only enabled after the first thread is created, so should have minimal overhead for non-concurrent execution.
- ~~Does not attempt to re-use thread id's so creating and joining threads lots of time in an execution will result in the vector clocks growing in size and slowing down program execution~~ It does now
