[COMPILETEST-UNTANGLE 4/N] Improve compiletest config documentation
This is part of a patch series to untangle `compiletest` to hopefully nudge it towards being more maintainable.
This PR should contain **no functional changes**.
This is pulled out to its own PR to make follow-up changes easier to review.
There are *intentionally* a *lot* of FIXME comments, intended to be gradually addressed in follow-ups.
r? `@Kobzol`
move `va_copy`, `va_arg` and `va_end` to `core::intrinsics`
some questions:
- should these functions be `pub`?
- is a separate module justified?
r? `@RalfJung`
codegen_ssa: replace a Result by an Either
`Err` here clearly does not indicate an "error" of any sort, so the use of `Result` is confusing. Let's use a sum type that does not come with the baggage of `Result`.
Pretend in bootstrap snapshot tests that we always build in-tree LLVM
Otherwise, depending on whether CI LLVM is inhibited or if an externally-provided LLVM is used, bootstrap host LLVM build step could be missing in step snapshots.
Note that I'm not sure if this is the *right* solution (this might be *a* solution). I imagine we do want to control for the set of configuration that these snapshot tests are run, as much as possible.
r? `@Kobzol`
Remove `Symbol` from `Named` variant of `BoundRegionKind`/`LateParamRegionKind`
The `Symbol` is redundant, since we already store a `DefId` in the region variant. Instead, load the name via `item_name` when needed (which is almost always on the diagnostic path).
This introduces a `BoundRegionKind::NamedAnon` which is used for giving anonymous bound regions names, but which should only be used during pretty printing and error reporting.
Fix CLI completion check in `tidy`
The list of CLI completion files that were generated and that were checked by `x test tidy` was not synced. Recently, some PR only updated some of the files, which caused the rest of the files (not checked by `x test tidy`) to be dirty on `master`. This PR fixes the logic in bootstrap to always synchronize the list of completion paths.
Fixes: https://github.com/rust-lang/rust/issues/143451
r? `@jieyouxu`
test passing a `VaList` from rust to C
Have C define various functions that take a `...` or `va_list` as an argument, and call them from rust. As far as I can see, this just wasn't actually tested before.
In particular this tests a difference between rust `VaList` and C `va_list` where C uses array-to-pointer decay, but rust cannot.
I've locally tested this for
- `x86_64-unknown-linux-gnu`
- `aarch64-unknown-linux-gnu`
- `s390x-unknown-linux-gnu`
- `powerpc64-unknown-linux-gnu`
- `powerpc64le-unknown-linux-gnu`
The latter 2 use an opaque pointer, the first 3 use a single-element array.
cc `@beetrees` if you see anything incorrect here
r? `@workingjubilee`
`tests/ui`: A New Order [25/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
`tests/ui`: A New Order [24/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
`tests/ui`: A New Order [22/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
`tests/ui`: A New Order [21/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
`tests/ui`: A New Order [18/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@tgross35`
`tests/ui`: A New Order [14/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
Allow `enum` and `union` literals to also create SSA values
Today, `Some(x)` always goes through an `alloca`, even in trivial cases where the niching means the constructor doesn't even change the value.
For example, <https://rust.godbolt.org/z/6KG6PqoYz>
```rust
pub fn demo(r: &i32) -> Option<&i32> {
Some(r)
}
```
currently emits the IR
```llvm
define align 4 ptr `@demo(ptr` align 4 %r) unnamed_addr {
start:
%_0 = alloca [8 x i8], align 8
store ptr %r, ptr %_0, align 8
%0 = load ptr, ptr %_0, align 8
ret ptr %0
}
```
but with this PR it becomes just
```llvm
define align 4 ptr `@demo(ptr` align 4 %r) unnamed_addr {
start:
ret ptr %r
}
```
(Of course the optimizer can clean that up, but it'd be nice if it didn't have to -- especially in debug where it doesn't run. This is like rust-lang/rust#123886, but that only handled non-simd `struct`s -- this PR generalizes it to all non-simd ADTs.)
Doing this means handing variants other than `FIRST_VARIANT`, handling the active field for unions, refactoring the discriminant code so the Place and Operand parts can share the calculation, etc.
Other PRs that led up to this one:
- https://github.com/rust-lang/rust/pull/142005
- https://github.com/rust-lang/rust/pull/142103
- https://github.com/rust-lang/rust/pull/142324
- https://github.com/rust-lang/rust/pull/142383
---
try-job: aarch64-gnu
clean up GVN TypeId test
addresses https://github.com/rust-lang/rust/pull/142789#discussion_r2184897992
This is an attempt to clarify what this test is actually supposed to test and make it less dependent on `TypeId` internals (it now depends on the output of `type_name` instead).
I verified that this version still miscompiles on `nightly-2025-02-11`.
r? ``@oli-obk`` ``@RalfJung``
remove special-casing of boxes from match exhaustiveness/usefulness analysis
As a first step in replacing `box_patterns` with `deref_patterns`, this treats box patterns as deref patterns in the THIR and exhaustiveness analysis. This allows a bunch of special-casing to be removed. The emitted MIR is unchanged.
Incidentally, this fixes a bug caused by box patterns being treated like structs rather than pointers, where enabling `exhaustive_patterns` (rust-lang/rust#51085) could give rise to spurious `unreachable_patterns` lints on arms required for exhaustiveness. Following the lint's advice to remove the match arm would result in an error. I'm not sure what the current state of `exhaustive_patterns` is with regard to reference/box opsem, or whether there's any intention to have `unreachable_patterns` be more granular than the whole arm, but regardless this should hopefully make them easier to handle consistently.
Tracking issue for deref patterns: rust-lang/rust#87121
r? `@Nadrieril`
Assign dependency bump PRs to me
These PRs sometimes get lost as GH reduces their visibility, so I wanted to get an assignment so I can help these PRs land
Orson Peters