Auto merge of #3047 - RalfJung:target-support, r=saethlin

update target support section

The MIPS targets were demoted to tier 3, so let's recommend a different big-endian target.

Also instead of listing the targets we test individually, just say we test all tier 1 targets.

r? `@rust-lang/miri`

src/tools/miri/README.md

@@ -156,7 +156,7 @@ program, no matter your host OS. This is particularly useful if you are using
 Windows, as the Linux target is much better supported than Windows targets.
 
 You can also use this to test platforms with different properties than your host
-platform. For example `cargo miri test --target mips64-unknown-linux-gnuabi64`
+platform. For example `cargo miri test --target s390x-unknown-linux-gnu`
 will run your test suite on a big-endian target, which is useful for testing
 endian-sensitive code.
 
@@ -220,20 +220,18 @@ using `--target`!
 The following targets are tested on CI and thus should always work (to the
 degree documented below):
 
-- The best-supported target is `x86_64-unknown-linux-gnu`. Miri releases are
-  blocked on things working with this target. Most other Linux targets should
-  also work well; we do run the test suite on `i686-unknown-linux-gnu` as a
-  32bit target and `mips64-unknown-linux-gnuabi64` as a big-endian target, as
-  well as the ARM targets `aarch64-unknown-linux-gnu` and
-  `arm-unknown-linux-gnueabi`.
-- `x86_64-apple-darwin` should work basically as well as Linux. We also test
-  `aarch64-apple-darwin`. However, we might ship Miri with a nightly even when
-  some features on these targets regress.
-- `x86_64-pc-windows-msvc` works, but supports fewer features than the Linux and
-  Apple targets. For example, file system access and concurrency are not
-  supported on Windows. We also test `i686-pc-windows-msvc`, with the same
-  reduced feature set. We might ship Miri with a nightly even when some features
-  on these targets regress.
+- All Rust [Tier 1 targets](https://doc.rust-lang.org/rustc/platform-support.html) are supported by
+  Miri. They are all checked on Miri's CI, and some (at least one per OS) are even checked on every
+  Rust PR, so the shipped Miri should always work on these targets.
+- We also support `s390x-unknown-linux-gnu` as our "big-endian target of choice".
+- For every other target with OS `linux`, `macos`, or `windows`, Miri should generally work, but we
+  make no promises.
+- For targets on other operating systems, even basic operations such as printing to the standard
+  output might not work, and Miri might fail before even reaching the `main` function.
+
+However, even for targets that we do support, the degree of support for accessing platform APIs
+(such as the file system) differs between targets: generally, Linux targets have the best support,
+and macOS targets are usually on par. Windows is supported less well.
 
 ### Running tests in parallel
 

src/tools/miri/ci.sh

@@ -116,7 +116,7 @@ case $HOST_TARGET in
     MIRI_TEST_TARGET=tests/avr.json MIRI_NO_STD=1 run_tests_minimal no_std # JSON target file
     ;;
   x86_64-apple-darwin)
-    MIRI_TEST_TARGET=mips64-unknown-linux-gnuabi64 run_tests # big-endian architecture
+    MIRI_TEST_TARGET=s390x-unknown-linux-gnu run_tests # big-endian architecture
     MIRI_TEST_TARGET=x86_64-pc-windows-msvc run_tests
     ;;
   i686-pc-windows-msvc)

src/tools/miri/tests/pass/function_calls/abi_compat.rs

@@ -1,7 +1,5 @@
-#![feature(portable_simd)]
 use std::mem;
 use std::num;
-use std::simd;
 
 #[derive(Copy, Clone)]
 struct Zst;
@@ -56,8 +54,7 @@ fn test_abi_newtype<T: Copy>(t: T) {
 
 fn main() {
     // Here we check:
-    // - unsigned vs signed integer is allowed
-    // - u32/i32 vs char is allowed
+    // - u32 vs char is allowed
     // - u32 vs NonZeroU32/Option<NonZeroU32> is allowed
     // - reference vs raw pointer is allowed
     // - references to things of the same size and alignment are allowed
@@ -65,10 +62,7 @@ fn main() {
     // these would be stably guaranteed. Code that relies on this is equivalent to code that relies
     // on the layout of `repr(Rust)` types. They are also fragile: the same mismatches in the fields
     // of a struct (even with `repr(C)`) will not always be accepted by Miri.
-    test_abi_compat(0u32, 0i32);
-    test_abi_compat(simd::u32x8::splat(1), simd::i32x8::splat(1));
     test_abi_compat(0u32, 'x');
-    test_abi_compat(0i32, 'x');
     test_abi_compat(42u32, num::NonZeroU32::new(1).unwrap());
     test_abi_compat(0u32, Some(num::NonZeroU32::new(1).unwrap()));
     test_abi_compat(&0u32, &0u32 as *const u32);
@@ -83,9 +77,6 @@ fn main() {
     test_abi_newtype(0u32);
     test_abi_newtype(0f32);
     test_abi_newtype((0u32, 1u32, 2u32));
-    // FIXME: skipping the array tests on mips64 due to https://github.com/rust-lang/rust/issues/115404
-    if !cfg!(target_arch = "mips64") {
-        test_abi_newtype([0u32, 1u32, 2u32]);
-        test_abi_newtype([0i32; 0]);
-    }
+    test_abi_newtype([0u32, 1u32, 2u32]);
+    test_abi_newtype([0i32; 0]);
 }