Auto merge of #86231 - nagisa:nagisa/abi-allowlist, r=petrochenkov

Replace per-target ABI denylist with an allowlist

It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.

This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.

In this PR we got rid of the per-target ABI denylists, and instead compute
which ABIs are supported with a simple match based on, mostly, the
`Target::arch` field. Among other things, this makes it impossible to
forget to consider this problem (in either direction) and forces one to
consider what the ABI support looks like when adding an ABI (rarely)
rather than target (often), which should hopefully also reduce the
cognitive load on both contributors as well as reviewers.

Fixes #57182

Sponsored by: standard.ai

---

## Summary for teams

One significant user-facing change after this PR is that there's now a future compat warning when building…

* `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*;
* `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*.

Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](#86231 (comment)) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another.

The intention is that this warning becomes a hard error after some time.

Author: bors

compiler/rustc_lint_defs/src/builtin.rs

@@ -2974,6 +2974,7 @@ declare_lint_pass! {
         LARGE_ASSIGNMENTS,
         FUTURE_PRELUDE_COLLISION,
         RESERVED_PREFIX,
+        UNSUPPORTED_CALLING_CONVENTIONS,
     ]
 }
 
@@ -3303,3 +3304,49 @@ declare_lint! {
     };
     crate_level_only
 }
+
+declare_lint! {
+    /// The `unsupported_calling_conventions` lint is output whenever there is an use of the
+    /// `stdcall`, `fastcall`, `thiscall`, `vectorcall` calling conventions (or their unwind
+    /// variants) on targets that cannot meaningfully be supported for the requested target.
+    ///
+    /// For example `stdcall` does not make much sense for a x86_64 or, more apparently, powerpc
+    /// code, because this calling convention was never specified for those targets.
+    ///
+    /// Historically MSVC toolchains have fallen back to the regular C calling convention for
+    /// targets other than x86, but Rust doesn't really see a similar need to introduce a similar
+    /// hack across many more targets.
+    ///
+    /// ### Example
+    ///
+    /// ```rust,ignore (needs specific targets)
+    /// extern "stdcall" fn stdcall() {}
+    /// ```
+    ///
+    /// This will produce:
+    ///
+    /// ```text
+    /// warning: use of calling convention not supported on this target
+    ///   --> $DIR/unsupported.rs:39:1
+    ///    |
+    /// LL | extern "stdcall" fn stdcall() {}
+    ///    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    ///    |
+    ///    = note: `#[warn(unsupported_calling_conventions)]` on by default
+    ///    = warning: this was previously accepted by the compiler but is being phased out;
+    ///               it will become a hard error in a future release!
+    ///    = note: for more information, see issue ...
+    /// ```
+    ///
+    /// ### Explanation
+    ///
+    /// On most of the targets the behaviour of `stdcall` and similar calling conventions is not
+    /// defined at all, but was previously accepted due to a bug in the implementation of the
+    /// compiler.
+    pub UNSUPPORTED_CALLING_CONVENTIONS,
+    Warn,
+    "use of unsupported calling convention",
+    @future_incompatible = FutureIncompatibleInfo {
+        reference: "issue #00000 <https://github.com/rust-lang/rust/issues/00000>",
+    };
+}

compiler/rustc_target/src/spec/aarch64_apple_ios.rs

@@ -2,7 +2,6 @@ use super::apple_sdk_base::{opts, Arch};
 use crate::spec::{FramePointer, Target, TargetOptions};
 
 pub fn target() -> Target {
-    let base = opts("ios", Arch::Arm64);
     Target {
         llvm_target: "arm64-apple-ios".to_string(),
         pointer_width: 64,
@@ -11,7 +10,6 @@ pub fn target() -> Target {
         options: TargetOptions {
             features: "+neon,+fp-armv8,+apple-a7".to_string(),
             max_atomic_width: Some(128),
-            unsupported_abis: super::arm_base::unsupported_abis(),
             forces_embed_bitcode: true,
             frame_pointer: FramePointer::NonLeaf,
             // Taken from a clang build on Xcode 11.4.1.
@@ -25,7 +23,7 @@ pub fn target() -> Target {
                 darwinpcs\0\
                 -Os\0"
                 .to_string(),
-            ..base
+            ..opts("ios", Arch::Arm64)
         },
     }
 }