-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace per-target ABI denylist with an allowlist #86231
Conversation
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
r? @petrochenkov, perhaps? (@varkor appears to be inactive) |
This comment has been minimized.
This comment has been minimized.
b58bf80
to
dd33daf
Compare
@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) |
⌛ Trying commit dd33daf4085fbdbf744e546a19c267af9d7b8acd with merge e0f03aec47b100bc29555561bd62a99d1bc6aca5... |
Certainly struggling to find time for larger PRs at the moment :) |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Regressions are:
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. |
dd33daf
to
125a793
Compare
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
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. Fixes rust-lang#57182 Sponsored by: standard.ai
95560b4
to
8240e7a
Compare
@bors r=petrochenkov |
📌 Commit 8240e7a has been approved by |
☀️ Test successful - checks-actions |
Fix the logic for custom vendor targets to account for refactoring of the aarch64-unknown-linux-gnu target upstream: rust-lang/rust#86231 Signed-off-by: Ben Cressey <bcressey@amazon.com>
Fix the logic for custom vendor targets to account for refactoring of the aarch64-unknown-linux-gnu target upstream: rust-lang/rust#86231 Signed-off-by: Ben Cressey <bcressey@amazon.com>
…ions, r= make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang#86231 (comment)) even when the PR was landed. This should get cratered, and I assume then it needs a t-compiler FCP. Fixes rust-lang#88397
…ntions, r=compiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang#86231 (comment)) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes rust-lang#87678
…ions, r=compiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang#86231 (comment)) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes rust-lang#87678
…ompiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang/rust#86231 (comment)) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes rust-lang/rust#87678
…ompiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang/rust#86231 (comment)) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes rust-lang/rust#87678
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 toforget 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
cfg
s and just happened to successfullycheck
on Linux for one reason or another.The intention is that this warning becomes a hard error after some time.