rust/tests/codegen-llvm
Stuart Cook 3a03bb9cbf
Rollup merge of #144567 - CaiWeiran:transmute-scalar_test, r=nikic
Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases

This PR resolves several test failures encountered when running `./x test` on the RISC-V architecture. These failures were caused by platform-specific behavior, ABI differences, or codegen inconsistencies unique to RISC-V.

The following test cases have been fixed to ensure compatibility with RISC-V:

* `codegen-llvm/enum/enum-match.rs`
* `codegen-llvm/enum/enum-transparent-extract.rs`
* `codegen-llvm/repeat-operand-zero-len.rs`
* `codegen-llvm/enum/enum-aggregate.rs`
* `codegen-llvm/uninhabited-transparent-return-abi.rs`

In addition, this PR adjusts `tests/codegen-llvm/transmute-scalar.rs` to explicitly specify the target architecture:

```rust
//@ compile-flags: --target=x86_64-unknown-linux-gnu
//@ needs-llvm-components: x86
```

As suggested by ```@nikic,``` this test is not target-specific and already uses `minicore`, implying it is meant to run against a stable triple regardless of the host architecture. Explicitly setting the target ensures consistent codegen behavior, particularly when testing on non-x86 platforms such as riscv64.

All changes have been tested locally on a RISC-V target and now pass as expected.

### Notes:

* These fixes are scoped specifically to enable full test suite compliance for RISC-V.
* No changes impact other architectures.
* The change to `transmute-scalar.rs` aligns with the intent of [[#143915](https://github.com/rust-lang/rust/pull/143915)](https://github.com/rust-lang/rust/pull/143915) and prevents architecture-dependent discrepancies during CI or local testing.
2025-08-19 14:18:19 +10:00
..

The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.

One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:

// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb

After specifying those variations, you can write different expected, or explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:, like so:

// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT:                        emitted-only-for-bbb
// bbb-NOT:  emitted-only-for-aaa
// bbb-SAME:                       emitted-only-for-bbb