Do not unify borrowed locals in CopyProp.
Instead of trying yet another scheme to unify borrowed locals in CopyProp, let's just stop trying. We had already enough miscompilations because of this.
I'm convinced it's possible to have both unification of some borrowed locals and soundness, but I don't have a simple and convincing formulation yet.
Fixes https://github.com/rust-lang/rust/issues/143491
Organize macro tests a bit more
- Move some macro parsing tests from `tests/ui/parser` to `tests/ui/parser/macro`.
- Most macro tests use `macro` in the name, making it easy to find and run tests relevant to macros. However, a few use `mbe` instead. Rename those to say `macro`.
Most macro tests use `macro` in the name, making it easy to find and run
tests relevant to macros. However, a few use `mbe` instead. Rename those
to say `macro`.
Stop using `Key` trait unnecessarily
Few places where the `Key` trait was being used but not really for a useful reason. This fixes those usages.
Namely, `<Ty as Key>::default_span()` is `DUMMY_SP` anyways.
`conv-bits-runtime-const` gates `f16` and `f128` tests behind `x86_64`,
but this isn't always accurate. In particular, x86 `MinGW` has an ABI
bug [1] which means things work when linked to our Rust math libraries
but don't work with host libraries. RUST-143405 slightly adjusts which
targets we provide `f16` and `f128` symbols for and effectively removes
MinGW from that list, meaning host libraries start getting linked,
meaning `f16` and `f128` tests start to fail.
Account for this by changing the gates in one such test to
`cfg(target_has_reliable_{f16,f128})` which is the way we should be
gating all behavior related to the types going forward.
`rustfmt` also seems to have formatted the macros which is fine.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
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.
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`
