Auto merge of rust-lang#138904 - madsmtm:apple-test-no-std, r=<try>

Test linking and running `no_std` binaries

I looked around, but it seems that we do not have a test that tests a `#![no_std]` + `#![no_main]` binary. So now I've added one. Motivated by discussion in [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507870028).

r? `@tgross35`

I haven't tested on Windows, so:
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2

And only tested lightly on Linux, so:
try-job: x86_64-linux

try-job: test-various

Author: bors

tests/ui/no_std/simple-runs.rs

@@ -0,0 +1,41 @@
+//! Check that `no_std` binaries can link and run without depending on `libstd`.
+
+//@ run-pass
+//@ compile-flags: -Cpanic=abort
+//@ ignore-wasm different `main` convention
+
+#![no_std]
+#![no_main]
+
+use core::ffi::{c_char, c_int};
+use core::panic::PanicInfo;
+
+// # Linux
+//
+// Linking `libc` is required by crt1.o, otherwise the linker fails with:
+// > /usr/bin/ld: in function `_start': undefined reference to `__libc_start_main'
+//
+// # Apple
+//
+// Linking `libSystem` is required, otherwise the linker fails with:
+// > ld: dynamic executables or dylibs must link with libSystem.dylib
+//
+// With the new linker introduced in Xcode 15, the error is instead:
+// > Undefined symbols: "dyld_stub_binder", referenced from: <initial-undefines>
+//
+// This _can_ be worked around by raising the deployment target with
+// MACOSX_DEPLOYMENT_TARGET=13.0, though it's a bit hard to test that while
+// still allowing the test suite to support running with older Xcode versions.
+#[cfg_attr(all(not(target_vendor = "apple"), unix), link(name = "c"))]
+#[cfg_attr(target_vendor = "apple", link(name = "System"))]
+extern "C" {}
+
+#[panic_handler]
+fn panic_handler(_info: &PanicInfo<'_>) -> ! {
+    loop {}
+}
+
+#[no_mangle]
+extern "C" fn main(_argc: c_int, _argv: *const *const c_char) -> c_int {
+    0
+}