Ban projecting into SIMD types [MCP838]
Closes https://github.com/rust-lang/compiler-team/issues/838
The actual compiler change here is tiny; there's just a bazillion tests to update.
~~Since I'm sure I've missed some, for now~~
~~r ghost~~
try-job: test-various
try-job: x86_64-gnu-nopt
Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
Add new `ignore-backends` and `needs-backends` tests annotations
Part of https://github.com/rust-lang/compiler-team/issues/891.
Next step will be to add these annotations in the files where either the output is different based on the codegen (like `asm` tests) or that are known to fail in the GCC backend.
cc `@oli-obk` `@antoyo`
r? `@Kobzol`
bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests
As dicussed in https://github.com/rust-lang/rust/issues/61117#issuecomment-495587364, codegen tests typically depend on the raw LLVM IR output and are sensitive to debuginfo level. So do not apply `rust.debuginfo-level-tests` for codegen tests.
Before this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s
After this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s
### Run this in CI?
Maybe it will make sense to add this to CI later but I think it is too early to do now before more non-codegen tests work with `rust.debuginfo-level-tests=2`.
bootstrap: Don't trigger an unnecessary LLVM build from check builds
Coming back to r-l/r development after a few weeks away, I found a major regression in my dev workflows: running `x check compiler` (either manually or via rust-analyzer) would have the side-effect of building LLVM, even though that shouldn't be necessary.
For my main build directory this would be a minor annoyance, but for my separate rust-analyzer build directory it's a huge problem because it causes a completely separate build of LLVM, which takes a long time and should be completely unnecessary.
---
After some investigation, I tracked down the problem to the `can_skip_build` check in this code:
3014e79f9c/src/bootstrap/src/core/build_steps/compile.rs (L1382-L1396)
Historically, this would skip the LLVM build for stage 0 check builds. But after the recent stage 0 std redesign and some associated check stage renumbering (e.g. rust-lang/rust#143048), the condition `builder.top_stage == build_stage` is now false, because `top_stage` is 1 (due to the renumbering) but `build_stage` is 0 (because a “stage 1” non-library check build still uses the stage 0 compiler).
---
Because this is a critical contributor roadblock for me, I have tried to fix this in a relatively narrow way. It's possible that all of this surrounding logic could be greatly simplified (especially in light of the stage redesign changes), but I didn't want this fix to be held back by scope creep.
---
(Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20incorrectly.20building.20LLVM.20for.20check.20builds/near/528991035)
[rustdoc] Make aliases search support partial matching
Fixesrust-lang/rust#140782.
To make this work, I moved aliases into the `searchIndex` like any other item. It links to the "original" item with a new `original` field. No so great part is that we need to have some fields like `bitIndex` to be set on the alias to make the description load to work but I consider it minor enough to be ok.
This PR voluntarily doesn't handle de-prioritization of aliases as ```@lolbinarycat``` wished to work on this so I'll leave them this part. 😉
cc ```@lolbinarycat```
tests: Require `run-fail` ui tests to have an exit code (`SIGABRT` not ok)
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement.
Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d` (`STATUS_ILLEGAL_INSTRUCTION`). Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests.
This adds further (cc https://github.com/rust-lang/rust/pull/142304, https://github.com/rust-lang/rust/pull/142886) protection against the regression in https://github.com/rust-lang/rust/issues/123733 since that bug also manifested as `SIGABRT` in `tests/ui/panics/panic-main.rs` (shown as `Aborted (core dumped)` in the logs attached to that issue, and I have also been able to reproduce this locally).
### TODO
- [x] **Q:** what about on Windows?
**A:** we'll treat any exit code outside of 1 - 127 as "crashed", and we'll do the same on unix.
- [x] test all permutations of actual vs expected
**Done:** See https://github.com/rust-lang/rust/pull/143002#issuecomment-3007502894.
- [x] Handle targets without unwind support
- [x] Add `run-fail-or-crash` for some sanitizer tests
- [x] remote-test-client. See https://github.com/rust-lang/rust/pull/143448
### Zulip discussion
See https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/compiletest.3A.20terminate.20by.20signal.20vs.20exit.20with.20error/with/525611235
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
try-job: armhf-gnu
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be
terminated by a signal like `SIGABRT`. So begin having that as a hard
requirement.
Some of our current tests do terminate by a signal/crash however.
Introduce and use `run-crash` for those tests. Note that Windows crashes
are not handled by signals but by certain high bits set on the process
exit code. Example exit code for crash on Windows: `0xc000001d`.
Because of this, we define "crash" on all platforms as "not exit with
success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with
failure code 101 after panicking. As a special case, allow crashes for
`run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems
differently. Some abort (crash) the process while others exit with
failure code 1. Introduce and use `run-fail-or-crash` for such tests.
Rename `optional-mingw-check-1` to `optional-pr-check-1`
I noticed this when doing a `bors2 try` for `mingw`.
I also changed it to use the `pr-check-1` image as `mingw-check-1` no longer exists.
