Fix ub-int-array test for big-endian platforms

As of commit 7767cbb3b0b332fd0a46e347ea7f68f20109d768,
the tests/ui/consts/const-eval/ub-int-array.rs test is
failing on big-endian platforms (in particular s390x),
as the stderr output contains a hex dump that depends
on endianness.

Since this point intentionally verifies the hex dump to
check the uninitialized byte markers, I think we should
not simply standardize away the hex dump as is done with
some of the other tests in this directory.

However, most of the test is already endian-independent.
The only exception is one line of hex dump, which can
also be made endian-independent by choosing appropriate
constants in the source code.

Since the 32bit and 64bit stderr outputs were already
(and remain) identical, I've merged them and removed
the stderr-per-bitwidth marker.

Fixes (again) https://github.com/rust-lang/rust/issues/105383.

1 files changed, 6 insertions, 2 deletions

diff --git a/tests/ui/consts/const-eval/ub-int-array.rs b/tests/ui/consts/const-eval/ub-int-array.rs
index adcf376b9c7..cde0749dc5f 100644
--- a/tests/ui/consts/const-eval/ub-int-array.rs
+++ b/tests/ui/consts/const-eval/ub-int-array.rs
@@ -1,4 +1,3 @@
-// stderr-per-bitwidth
 //! Test the "array of int" fast path in validity checking, and in particular whether it
 //! points at the right array element.
 
@@ -19,7 +18,12 @@ impl<T: Copy> MaybeUninit<T> {
 const UNINIT_INT_0: [u32; 3] = unsafe {
     //~^ ERROR it is undefined behavior to use this value
     //~| invalid value at [0]
-    mem::transmute([MaybeUninit { uninit: () }, MaybeUninit::new(1), MaybeUninit::new(2)])
+    mem::transmute([
+        MaybeUninit { uninit: () },
+        // Constants chosen to achieve endianness-independent hex dump.
+        MaybeUninit::new(0x11111111),
+        MaybeUninit::new(0x22222222),
+    ])
 };
 const UNINIT_INT_1: [u32; 3] = unsafe {
     //~^ ERROR it is undefined behavior to use this value