Skip to content
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

Merged
merged 1 commit into from
Jul 6, 2021

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Jun 11, 2021

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
Copy link
Collaborator

r? @varkor

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 11, 2021
@nagisa
Copy link
Member Author

nagisa commented Jun 11, 2021

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

@rust-log-analyzer

This comment has been minimized.

@nagisa
Copy link
Member Author

nagisa commented Jun 11, 2021

@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
Copy link
Contributor

bors commented Jun 11, 2021

⌛ Trying commit dd33daf4085fbdbf744e546a19c267af9d7b8acd with merge e0f03aec47b100bc29555561bd62a99d1bc6aca5...

@varkor
Copy link
Member

varkor commented Jun 11, 2021

(@varkor appears to be inactive)

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

@bors
Copy link
Contributor

bors commented Jun 11, 2021

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

@nagisa

This comment has been minimized.

@craterbot

This comment has been minimized.

@nagisa

This comment has been minimized.

@craterbot

This comment has been minimized.

@nagisa
Copy link
Member Author

nagisa commented Jun 11, 2021

@craterbot check

@craterbot
Copy link
Collaborator

👌 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 craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 11, 2021
@craterbot
Copy link
Collaborator

🚧 Experiment pr-86231 is now running

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

@craterbot
Copy link
Collaborator

🎉 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

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jun 21, 2021
@nagisa
Copy link
Member Author

nagisa commented Jun 21, 2021

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.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Jul 6, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 6, 2021
@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 6, 2021
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
@nagisa
Copy link
Member Author

nagisa commented Jul 6, 2021

@bors r=petrochenkov

@bors
Copy link
Contributor

bors commented Jul 6, 2021

📌 Commit 8240e7a has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 6, 2021
@bors
Copy link
Contributor

bors commented Jul 6, 2021

⌛ Testing commit 8240e7a with merge b09dad3...

@bors
Copy link
Contributor

bors commented Jul 6, 2021

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 6, 2021
@bors bors merged commit b09dad3 into rust-lang:master Jul 6, 2021
@rustbot rustbot added this to the 1.55.0 milestone Jul 6, 2021
bcressey added a commit to bcressey/bottlerocket-sdk that referenced this pull request Oct 5, 2021
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>
bcressey added a commit to bcressey/bottlerocket-sdk that referenced this pull request Oct 23, 2021
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>
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 3, 2024
…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
fmease added a commit to fmease/rust that referenced this pull request Oct 22, 2024
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 22, 2024
…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
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Oct 30, 2024
…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
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request Oct 31, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

AAPCS ABI is accepted for x86 target
8 participants