Replace per-target ABI denylist with an allowlist

[nagisa]

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 that we see are mostly about Windows-specific code that was missing relevant cfgs 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.

[rust-highfive]

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

[nagisa]

r? @petrochenkov, perhaps? (@varkor appears to be inactive)

[nagisa]

@bors try (this will want a crater run – the PR restricts ABIs, some of which are stable and can be used in ill-formed ways)

[bors]

⌛ Trying commit dd33daf4085fbdbf744e546a19c267af9d7b8acd with merge e0f03aec47b100bc29555561bd62a99d1bc6aca5...

[varkor]

(@varkor appears to be inactive)

Certainly struggling to find time for larger PRs at the moment :)

[bors]

☀️ Try build successful - checks-actions
Build commit: e0f03aec47b100bc29555561bd62a99d1bc6aca5 (e0f03aec47b100bc29555561bd62a99d1bc6aca5)

[nagisa]

@craterbot check

[craterbot]

👌 Experiment pr-86231 created and queued.
🤖 Automatically detected try build e0f03aec47b100bc29555561bd62a99d1bc6aca5
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-86231 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-86231 is completed!
📊 34 regressed and 11 fixed (167538 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[nagisa]

Regressions are:

• couple download failures in a build.rs script of rusty_v8 or similar system-related problems;
• a fair number of crates using "stdcall" ABI (in not cfg-d out on linux, but otherwise usually windows specific, code).

I believe the first class of errors is most likely unrelated to this PR and the second class of errors is likely an expected consequence that we cannot do much about other than going through the ecosystem crates and fixing them. Most of the affected crates are already platform specific anyway, and the fallout is fairly limited AFAICT.

[nagisa]

@bors r=petrochenkov

[bors]

📌 Commit 8240e7a has been approved by petrochenkov

[bors]

⌛ Testing commit 8240e7a with merge b09dad3...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing b09dad3 to master...