use short message format in integration test
While checking #12983, bors came upon a cargo change that put "E0463" into the standard error (as part of a test case code snippet), which the integration test picked up to fail the build. Talk about unforeseen consequences.
So this PR just changes the integration test to use short message format in order to not include the code snippets in the output. Hopefully that will fix the problem.
r? `@Alexendoo`
---
changelog: none
Replace `f16` and `f128` pattern matching stubs with real implementations
This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now.
r? `@Nadrieril`
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.
This also fixes some missing range and match handling in `rustc_middle`.
Support absolute source paths in bootstrap
Fixes https://github.com/rust-lang/rust/issues/126765
`x test [PATHS]` should work when each path
1. Is the name of a build step, such as `tidy` in `x test tidy` or
2. Points to an existing file that is a descendant of the builder's source directory (root of this repository).
Try to clarify the confusingly-named `RustDev` and `RustcDev` steps
When trying to track down how the downloaded LLVM gets built and bundled, I was greatly confused by these step names.
I wasn't sure whether I could just rename them (since they correspond to the filename of the resulting tarball), but I at least wanted to leave behind some signposts to reduce confusion.
Ignore `branch-protection-check-IBT` run-make test
The old Makefile implementation (#110304) had an improper comparison which caused the test to never run. However, both the updated Makefile implementation and the rmake implementation fail (missing `.note.gnu.property`). This could be a bug in the original implementation or test flakiness.
Edit: Manually recreating the test case shows that `.note.gnu.property` does not appear in nightly.
```rust
// main.rs
fn main() {
println!("hello world");
}
```
```sh
$ rustc +nightly -V
rustc 1.81.0-nightly (c1b336cb6 2024-06-21)
$ rustc +stable -V
rustc 1.79.0 (129f3b996 2024-06-10)
```
```sh
$ rustc +nightly -Zcf-protection=branch -Clink-args=-nostartfiles -Csave-temps "-L$PWD" main.rs -o main
$ llvm-readobj --elf-output-style=GNU -nW main
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000008 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: bcae34e6431b2a37
```
Compiling without the other flags still does not show `.note.gnu.property`.
```sh
$ rustc +nightly main.rs -o main
$ llvm-readobj --elf-output-style=GNU -nW main
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 4.4.0
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000008 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: d60d5f108b63bf3a
```
Compiling on stable shows `.note.gnu.property`.
```sh
$ rustc +stable main.rs -o main
$ llvm-readobj --elf-output-style=GNU -nW main
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 (property note)
Properties: x86 ISA needed: x86-64-baseline
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 4a494eb578123314e6ff1caf1c8877e27004664f
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 4.4.0
```
Part of #121876.
r? `@jieyouxu`
Merge `PatParam`/`PatWithOr`, and `Expr`/`Expr2021`, for a few reasons.
- It's conceptually nice, because the two pattern kinds and the two
expression kinds are very similar.
- With expressions in particular, there are several places where both
expression kinds get the same treatment.
- It removes one unreachable match arm.
- Most importantly, for #124141 I will need to introduce a new type
`MetaVarKind` that is very similar to `NonterminalKind`, but records a
couple of extra fields for expression metavars. It's nicer to have a
single `MetaVarKind::Expr` expression variant to hold those extra
fields instead of duplicating them across two variants
`MetaVarKind::{Expr,Expr2021}`. And then it makes sense for patterns
to be treated the same way, and for `NonterminalKind` to also be
treated the same way.
I also clarified the comments, because I have long found them a little
hard to understand.
resolve `clippy::invalid_paths` on `bool::then`
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
