Add tests for the generated assembly of mask related simd instructions.
The tests show that the code generation currently uses the least significant bits of <iX x N> vector masks when converting to <i1 xN>. This leads to an additional left shift operation in the assembly for x86, since mask operations on x86 operate based on the most significant bit.
The exception is simd_bitmask, which already uses the most-significant bit.
This additional instruction would be removed by the changes in #104693, which makes all mask operations consistently use the most significant bits.
By using the "C" calling convention the tests should be stable regarding changes in register allocation, but it is possible that future llvm updates will require updating some of the checks.
[bootstrap] Move the `split-debuginfo` setting to the per-target section
As described in #112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple.
This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example).
However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`).
#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well.
This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change.
---
After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now.
This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple.
---
If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
Ensure nested allocations in statics neither get deduplicated nor duplicated
This PR generates new `DefId`s for nested allocations in static items and feeds all the right queries to make the compiler believe these are regular `static` items. I chose this design, because all other designs are fragile and make the compiler horribly complex for such a niche use case.
At present this wrecks incremental compilation performance *in case nested allocations exist* (because any query creating a `DefId` will be recomputed and never loaded from the cache). This will be resolved later in https://github.com/rust-lang/rust/pull/115613 . All other statics are unaffected by this change and will not have performance regressions (heh, famous last words)
This PR contains various smaller refactorings that can be pulled out into separate PRs. It is best reviewed commit-by-commit. The last commit is where the actual magic happens.
r? `@RalfJung` on the const interner and engine changes
fixes https://github.com/rust-lang/rust/issues/79738
Rename `wasm32-wasi-preview1-threads` to `wasm32-wasip1-threads`
This commit renames the current `wasm32-wasi-preview1-threads` target to `wasm32-wasip1-threads`. The need for this rename is a bit unfortunate as the previous name was chosen in an attempt to be future-compatible with other WASI targets. Originally this target was proposed to be `wasm32-wasi-threads`, and that's what was originally implemented in wasi-sdk as well. After discussion though and with the plans for the upcoming component-model target (now named `wasm32-wasip2`) the "preview1" naming was chosen for the threads-based target. The WASI subgroup later decided that it was time to drop the "preview" terminology and recommends "pX" instead, hence previous PRs to add `wasm32-wasip2` and rename `wasm32-wasi` to `wasm32-wasip1`.
So, with all that history, the "proper name" for this target is different than its current name, so one way or another a rename is required. This PR proposes renaming this target cold-turkey, unlike `wasm32-wasi` which is having a long transition period to change its name. The threads-based target is predicted to see only a fraction of the traffic of `wasm32-wasi` due to the unstable nature of the WASI threads proposal itself.
While I was here I updated the in-tree documentation in the target spec file itself as most of the documentation was copied from the original WASI target and wasn't as applicable to this target.
Also, as an aside, I can at least try to apologize for all the naming confusion here, but this is hopefully the last WASI-related rename.
The tests show that the code generation currently uses the least
significant bits of <iX x N> vector masks when converting to <i1 xN>.
This leads to an additional left shift operation in the assembly for
x86, since mask operations on x86 operate based on the most significant
bit. On aarch64 the left shift is followed by a comparison against zero,
which repeats the sign bit across the whole lane.
The exception, which does not introduce an unneeded shift, is
simd_bitmask, because the code generation already shifts before
truncating.
By using the "C" calling convention the tests should be stable regarding
changes in register allocation, but it is possible that future llvm
updates will require updating some of the checks.
This additional instruction would be removed by the fix in #104693,
which uses the most significant bit for all mask operations.
Rollup of 8 pull requests
Successful merges:
- #115141 (Update Windows platform support)
- #121865 (Add FileCheck annotations to MIR-opt unnamed-fields tests)
- #122000 (Fix 32-bit overflows in LLVM composite constants)
- #122194 (Enable creating backtraces via -Ztreat-err-as-bug when stashing errors)
- #122319 (Don't ICE when non-self part of trait goal is constrained in new solver)
- #122339 (Update books)
- #122342 (Update /NODEFAUTLIB comment for msvc)
- #122343 (Remove some unnecessary `allow(incomplete_features)` in the test suite)
r? `@ghost`
`@rustbot` modify labels: rollup
Update /NODEFAUTLIB comment for msvc
I've tried to explain a bit more about the effects of `/NODEFAULTLIB` when using msvc link.exe (or compatible) as they're different from `-nodefaultlib` on gnu.
I also removed the part about licensing as I'm not sure licensing is an issue? Or rather, it's no more or less of an issue no matter how you link msvc libraries. The license is the one you get if using VS at all and even dynamic linking includes static code (e.g. startup/shutdown code, etc).
r? petrochenkov
Enable creating backtraces via -Ztreat-err-as-bug when stashing errors
r? `@nnethercote`
Otherwise I can't debug stashed errors because I can't find their source
Fix 32-bit overflows in LLVM composite constants
Inspired by #121868. Fixes unsoundness created when constructing constant arrays, strings, and structs with 2^32 or more elements on x86_64. This introduces copies of a few LLVM functions that have their signatures updated to use size_t in place of unsigned int. Alternatively we could just add overflow checks and just disallow huge composite constants. That introduces less code, but maybe a huge static block of memory is useful in embedded/no-os situations?
Add FileCheck annotations to MIR-opt unnamed-fields tests
Part of #116971
Adds filecheck annotations to unnamed-fields mir-opt tests in `tests/mir-opt/unnamed-fields`
Update Windows platform support
This should not be merged until Rust 1.76 but I'm told this may need an fcp in addition to [MCP 651](https://github.com/rust-lang/compiler-team/issues/651).
cc ```@rust-lang/compiler``` ```@rust-lang/release```
This is implemented, in addition to the ML-style one,
because Rust does it. If we don't, we'll never hear the end of it.
This commit also refactors some duplicate parts of the parser
into a dedicated function.
Option::map, for example, looks like this:
option<t>, (t -> u) -> option<u>
This syntax searches all of the HOFs in Rust: traits Fn, FnOnce,
and FnMut, and bare fn primitives.
Lower transmutes from int to pointer type as gep on null
I thought of this while looking at https://github.com/rust-lang/rust/pull/121242. See that PR's description for why this lowering is preferable.
The UI test that's being changed here crashes without changing the transmutes into casts. Based on that, this PR should not be merged without a crater build-and-test run.
