stacked borrows: ensure array-to-elem casts behave correctly
When "as"-casting an entire array, that should create a raw ptr usable for all elements in the array, even if we immediately cast to the element type.
Throw UB if f*_fast intrinsic called with non-finite value
Calling these intrinsics with non-finite values is undefined behaviour, since they result in `f*` intrinsics in LLVM with the `fast` flag, and `fast` math on non-finite values results in `poison` values. (technically LLVM only considers it UB upon _using_ the value, but that shouldn't make much of a difference)
Use `harness = false` instead of `#![feature(custom_test_frameworks)]`
Quoting from the comment in `tests/compiletest.rs`:
> Custom test runner, to avoid libtest being wrapped around compiletest which wraps libtest.
I believe `harness = false` is more suitable for that purpose.
I have verified that both `./miri test` and `LD_LIBRARY_PATH=$PWD/build/x86_64-unknown-linux-gnu/stage2/lib PATH=$PWD/build/bin:$PATH ./x.py test src/tools/miri` work well.
remove compatibility code for passing miri flags via cargo arguments
With https://github.com/rust-lang/miri/pull/1540, we deprecated `cargo miri test -- -Zmiri-disable-stacked-borrows` as a style of passing flags to Miri, introducing `MIRIFLAGS="-Zmiri-disable-stacked-borrows" cargo miri test` instead. This made `cargo miri` more compatible with `cargo`; both now behave the same in terms of argument parsing.
However, to avoid breaking things, I introduced some backwards compatibility hack such that the old way would still work. Six months later, I think it is time to remove that hack.
fix MIRI_BE_RUSTC value during sysroot build
`@hyd-dev` pointed out that `MIRI_BE_RUSTC` is set to an incorrect value during the xargo sysroot build. This fixes that.
only check timeouts when a thread yields
Currently, we check for expired timeouts after each step of execution. That seems excessive. This changes the scheduler to only check for timeouts when the active thread cannot continue running any more.
`@vakaras` does this sound right? `pthread_cond_timedwait` anyway already yields, of course, since it blocks on getting the signal (or the timeout).
