Passes LLVM codegen and Emscripten link-time flags for exception
handling if and only if the panic strategy is `unwind`. Sets the
default panic strategy for Emscripten targets to `unwind`. Re-enables
tests that depend on unwinding support for Emscripten, including
`should_panic` tests.
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
Enhance report-time option
## Short overview
This PR is a follow-up to a previously closed#64714 PR.
## Changes introduced by this PR
* `libtest` now retrieves the type of the test within `TestDesc` (available types are: `UnitTest`, `IntegrationTest`, `DocTest`, `Unknown`).
* `--report-time` subcommand of the `libtest` now supports colored output (disabled by default).
* Colorized output depends on the threshold values. Default values (proposed by @wesleywiser):
- For unit-tests: 50ms warn/100ms critical,
- For integration-tests: 500ms warn/1000ms critical,
- For doctests: same as for integration tests,
- For unknown tests: `TEST_WARN_TIMEOUT_S` warn/ `TEST_WARN_TIMEOUT_S * 2` critical (it will only applied single-threaded mode, because otherwise test will be interrupted after reaching `TEST_WARN_TIMEOUT_S`).
- These values can be overrided by setting environment variables (since those thresholds are somewhat constant for every project, it's more flexible to use environment variables than command line arguments).
* New optional flag `--ensure-test-time` for `libtest`. With this flag applied, exectuion time limit excesss will cause test failure.
## What have not been done
There was a comment that it would be nice to have an entry in the Cargo book about it.
However, changes introduced by this PR (and #64663 in which `report-time` flag was added) aren't related directly to `cargo`, it's more about `libtest` itself.
I'm considering that [The Unstable Book](https://doc.rust-lang.org/unstable-book/) is more appropriate place, but not sure if I'm right (and if so, how exactly it should be described).
As one possible option, this PR may be merged without denoting it in the documentation, and in the next PR adding support of this feature to the `cargo` itself, I'll add a note in the Cargo book.
## Scope of this PR
Logical scope of this PR is `libtest` only. However, to get test types, I had to modify also `libsyntax_ext` and `librustdoc` for them to provide information about test type.
## Rationale
Rationale for colored output was submitted in #64714
Providing the information about kind of test was also proposed in #64714, and as an additional benefit this information may be useful for the tools using `libtest` (e.g. `cargo`).
Adding flag to treat time limits excess seems logical to me, so projects that do care about test execution time won't have to invent a wheel.
## Backward compatibility
All the changes are completely backward compatible.
## Demo
r? @wesleywiser
libtest: add --show-output flag to print stdout of successful tests
This pull request adds a new flag `--show-output` for tests to show the output of successful tests. For most formatters this was already supported just not exposed via the CLI (apparently only used by `librustdoc`). I've also added support for this option in the JSON formatter.
This kind of fixes https://github.com/rust-lang/rust/issues/54669 which wants `--format json` to work with `--nocapture`, which is... well, impossible. What this issue really calls for is `--show-output` as implemented here.
Enable thumbv7a-pc-windows-msvc target build end to end in rust/master
With this PR, plus another commit cf98161da7, I'm able to build the target thumbv7a-pc-windows-msvc successfully, and I'm able to use the stage2 artifacts to build arm32 projects. The commit in compiler_builtins is in release 0.1.14, the current cargo.lock in rust master still uses 0.1.12, so I bumped the compiler_builtins version in cargo.lock to 0.1.15
The command I used to build rust
```
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc --verbose
```
**Changes**
1. update cargolock to use compiler_builtins 0.1.15
2. handle libunwind in libtest for thumv7a the same as what we have for aarch64
3. in llvm codegen add a field in CodegenContext to carry the arch, so later in create_msvc_imps function, the arch can be used to check against "x86", instead of 32 pointer width. Apparently Thumv7a is handled differently than x86.
**Background**
I'm from Microsoft working on enabling Azure IoTEdge on ARM32 Windows IoTCore, Azure IoTEdge has a component called IoTEdged written in rust as a NT service running on Windows, so we need to enable rust on thumbv7a in order to have full IoTEdge. My colleague had made some heavy lifting and we've been using our private toolchain to build IoTEdged in our devops pipeline, because at that time we cannot build thumbv7a target end to end successfully. This change is a followup to enable the end to end build for thumbv7a-pc-windows-msvc target.
**Next step**
I'll submit more changes to have this target built nightly in rust/master, to achieve the same availability for aarch64-pc-windows-msvc, indexed here https://rust-lang.github.io/rustup-components-history/aarch64-pc-windows-msvc.html and can be manually installed. **Please do share what takes to make this happen, is there a formal process I need to follow\?**
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! (note: if that RFC ever gets merged,
the API, docs, etc. of this API will need to change).
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways.
