Add a new `wasm32-wasi-preview2` target
This is the initial implementation of the MCP https://github.com/rust-lang/compiler-team/issues/694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](https://github.com/rust-lang/compiler-team/issues/694).
There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
* A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](https://github.com/rust-lang/compiler-team/issues/695) which has also been seconded and will hopefully be officially approved soon.
Additional technical details include:
* Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away.
* Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](https://github.com/WebAssembly/wasi-sdk/pull/370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.
* This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
rename 'try' intrinsic to 'catch_unwind'
The intrinsic has nothing to do with `try` blocks, and corresponds to the stable `catch_unwind` function, so this makes a lot more sense IMO.
Also rename Miri's special function while we are at it, to reflect the level of abstraction it works on: it's an unwinding mechanism, on which Rust implements panics.
Rollup of 6 pull requests
Successful merges:
- #121389 (llvm-wrapper: fix few warnings)
- #121493 (By changing some attributes to only_local, reducing encoding attributes in the crate metadate.)
- #121615 (Move `emit_stashed_diagnostic` call in rustfmt.)
- #121617 (Actually use the right closure kind when checking async Fn goals)
- #121628 (Do not const prop unions)
- #121629 (fix some references to no-longer-existing ReprOptions.layout_seed)
r? `@ghost`
`@rustbot` modify labels: rollup
Move `emit_stashed_diagnostic` call in rustfmt.
This call was added to `parse_crate_mod` in #121487, to fix a case where a stashed diagnostic wasn't emitted. But there is another path where a stashed diagnostic might fail to be emitted if there's a parse error, if the `build` call in `parse_crate_inner` fails before `parse_crate_mod` is reached.
So this commit moves the `emit_stashed_diagnostic` call outwards, from `parse_crate_mod` to `format_project`, just after the `Parser::parse_crate` call. This should be far out enough to catch any parsing errors.
Fixes#121517.
r? `@oli-obk`
cc `@ytmimi`
Correctly handle if rustdoc JS script hash changed
It's something that annoyed me for quite some time: I have nightly docs open (for both std and compiler). And often, I don't look at the page for some days. Then when I come back to it, I make a search... except nothing happens. Took me a while to figure out that it was because the hash of one of the JS files we load for the search (either `search.js` or `search-index.js`) was updated in the meantime, preventing the search to be done. To go around it, I added to press `ENTER` to make the form submitted (which would reload the same page but with the correct hashes this time and the search being run).
r? `@notriddle`
Allow tests to specify a `//@ filecheck-flags:` header
This allows individual codegen/assembly/mir-opt tests to pass extra flags to the LLVM `filecheck` tool as needed.
---
The original motivation was noticing that `tests/run-make/instrument-coverage` was very close to being an ordinary codegen test, except that it needs some extra logic to set up platform-specific variables to be passed into filecheck.
I then saw the comment in `verify_with_filecheck` indicating that a `filecheck-flags` header might be useful for other purposes as well.
This call was added to `parse_crate_mod` in #121487, to fix a case where
a stashed diagnostic wasn't emitted. But there is another path where a
stashed diagnostic might fail to be emitted if there's a parse error, if
the `build` call in `parse_crate_inner` fails before `parse_crate_mod`
is reached.
So this commit moves the `emit_stashed_diagnostic` call outwards, from
`parse_crate_mod` to `format_project`, just after the
`Parser::parse_crate` call. This should be far out enough to catch any
parsing errors.
Fixes#121517.
Improvements to building and CI for mingw/msys
I was getting error messages when trying to follow the build instructions the mingw build for Rust, and managed to track the issue down to an incomparability of Rust's bootstrap program with MSYS2's version of git. Essentially, the problem is that MSYS2's git works in emulated unix-y paths, but bootstrap expects a Windows path. I found a workaround for this by using relative paths instead of absolute paths.
Along with that fix, this PR also updates the build instructions for MinGW to be compatible with modern versions of MSYS2, and some changes to CI to make sure that MSYS2's version of git is tested. In particular, I'm suggesting using the [MSYS2 github action](https://github.com/marketplace/actions/setup-msys2) specially made for this purpose, which is much less hacky than the old approach and gives us more control of what packages are installed. I also cleaned up as many alternate versions of key tools as I could find from PATH, to avoid accidental usage, and cleaned up some abuses of the `CUSTOM_MINGW` environment variable.
This fixes https://github.com/rust-lang/rust/issues/105696 and fixes https://github.com/rust-lang/rust/issues/117567
Make most bootstrap step types !Copy
This makes all bootstrap types except for `Compiler` and `TargetSelection` `!Copy`. This makes it easier to modify them by adding !Copy types in the future, something that `@saethlin` has complained about before, and comes at no cost of code clarity, the impls were completely unused.
Making `Compiler` and `TargetSelection` `!Copy` (which would allow getting rid of interning) is highly nontrivial as they are used and copied **all over the place**. This should hopefully get most of the benefits.
Add newtypes for bool fields/params/return types
Fixed all the cases of this found with some simple searches for `*/ bool` and `bool /*`; probably many more
Windows: Use ProcessPrng for random keys
Windows 10 introduced [`ProcessPrng`](https://learn.microsoft.com/en-us/windows/win32/seccng/processprng) for random number generation. This allows us to replace the overly complicated (and prone to failure) `BCryptGenRandom` with a documented function.
For the tier 3 Windows 7 target, we simply use the older `RtlGenRandom`, which is undocumented. It should be fine even on modern systems (for comparability reasons) as it's just a wrapper for `ProcessPrng`. However, it does require loading an extra intermediary DLL which we can avoid when we know we have Windows 10+.
speed up `x install` by skipping archiving and compression
Performing archiving and compression on `x install` is nothing more than a waste of time and resources. Additionally, for systems like gentoo(which uses `x install`) this should be highly beneficial.
[benchmark report](https://github.com/rust-lang/rust/pull/118724#issuecomment-1848964908)
Resolves#109308
r? Mark-Simulacrum (I think you want to review this, feel free to change it if otherwise.)
This makes all bootstrap types except for `Compiler` and
`TargetSelection` `!Copy`. This makes it easier to modify them by adding
!Copy types in the future and comes at no cost of code clarity, the
impls were completely unused.
compiletest: call cargo-miri directly rather than via 'cargo run'
Fixes https://github.com/rust-lang/miri/issues/3297. Thanks to `@bjorn3` for figuring out the cause of this.
r? `@oli-obk`
Add "cargo miri clean" command
My first reaction when my miri cache was messed up was to attempt run this, which obviously failed. This helps paper over platform differences and such.
Windows miri-script execution egronomics
This allows for Windows users to use miri-script without pain. As working on miri earlier I was doing
`.\miri-script\target\debug\miri-script.exe { install | build | ... }` which wasn't fun.
Ignore less tests in debug builds
Since https://github.com/rust-lang/rust/pull/120594 and https://github.com/rust-lang/rust/pull/120863, nearly all UB-detecting debug assertions get compiled out of code that is monomorphized by a crate built with debug assertions disabled.
Which means that if we default all our codegen tests to `-Cdebug-assertions=no`, most of them work just fine against a sysroot built with debug assertions.
I also tried to explain a bit better why some tests need to be skipped, for those that still need to be skipped.
Rustdoc: include crate name in links for local primitives
Fixes#121106.
This change makes links to primitives easier to use when the path of the page where they will be embedded is not known beforehand such as when we generate impls dynamically from the `register_type_impls` method in `main.js`, which is exactly what is happening in #121106.
An example to show the effect of this change: earlier, if the current page in `cx.current` inside `primitive_link_fragment()` was `std::simd::prelude::Simd` the generated path would be `../../primitive.<prim>.html`. Now it would be `../../../std/primitive.<prim>.html` instead.
A side effect of the change is that local primitive links _everywhere_ will now contain the crate name, even outside of the dynamic situation mentioned above. I'm not sure if there are any major downsides of that other than making the links a bit longer. Ideally I wanted to restrict this behaviour change to only the dynamic cases. We could have achieved that by passing an additional bool arg to `primitive_link_fragment()`, but it felt awkward to do so. Any alternative suggestions are welcome.
It makes the link easier to use in cases in which
the path of the page where it will be embedded is not
known beforehand such as when we generate impls
dynamically from `register_type_impls` method in
`main.js`
Earlier for local primitives we would generate a path
that was relative to the current page depth passed in `cx.current`
. e.g if the current page was `std::simd::prelude::Simd` the
generated path would be `../../primitive.<prim>.html` After this
change the path will first take you to the the wesite root and add
the crate name. e.g. for `std::simd::prelude::Simd` the path now
will be `../../../std/primitive.<prim>.html`
