`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`
The `rustc` probe done in our build scripts needs to pass `--target` to
get the correct configuration, which usually comes from the `TARGET`
environment variable. However, for targets specified via a `target.json`
file, `TARGET` gets set to the file name without an extension or path.
`rustc` will check a search path to attempt to locate the file, but this
is likely to fail since the directory where Cargo invokes build scripts
(and hence where those scripts invoke `rustc`) might not have any
relation to the JSON spec file.
Resolve this for now by leaving `f16` and `f128` disabled if the `rustc`
command fails. Result of the discussion at CARGO-14208 may eventually
provide a better solution.
A CI test is also added since custom JSON files are an edge case that
could fail in other ways. I verified this fails without the fix here.
The JSON file is the output for `thumbv7em-none-eabi`, just renamed so
`rustc` doesn't identify it.
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
8521530f4938 ("Fix __divsi3 and __udivsi3 on thumbv6m targets") removed
tests that use these `thumb*-linux` target files in favor of tests that
use the `thumb*-none` targets, which are available via Rustup. The JSON
files haven't been used since then and are outdated, so remove them.
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
If the remote process is terminated by a signal, make `remote-test-client` exit
with the code `128 + <signal-number>` instead of always `3`. This follows common
practice among tools such as bash [^1]:
> When a command terminates on a fatal signal whose number is N, Bash uses the
> value 128+N as the exit status.
It also allows us to differentiate between `run-pass` and `run-crash` ui tests
without special case code in compiletest for that when `remote-test-client` is
used.
[^1]: https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html
