Skip to content

add (back) unsupported_calling_conventions lint to reject more invalid calling conventions #141435

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented May 23, 2025

This adds back the unsupported_calling_conventions lint that was removed in #129935, in order to start the process of dealing with #137018. Specifically, we are going for the plan laid out here:

  • thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
  • vectorcall should only be accepted on x86-32 and x86-64

The difference to the status quo is that:

  • We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
  • We stop accepting cdecl on targets that are non-x86-32
  • (There is no difference for thiscall, this was already a hard error on non-x86-32)
  • We stop accepting vectorcall on targets that are windows && non-x86-*

Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the unsupported_calling_conventions forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.

@rustbot
Copy link
Collaborator

rustbot commented May 23, 2025

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot
Copy link
Collaborator

rustbot commented May 23, 2025

These commits modify compiler targets.
(See the Target Tier Policy.)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 23, 2025
@RalfJung RalfJung force-pushed the unsupported_calling_conventions branch 2 times, most recently from 3251270 to f4146aa Compare May 23, 2025 12:02
also unify error messages that do not seem to have a good reason to be different
@RalfJung RalfJung force-pushed the unsupported_calling_conventions branch from f4146aa to b8f4367 Compare May 23, 2025 12:09
@RalfJung RalfJung added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label May 23, 2025
@RalfJung
Copy link
Member Author

@rust-lang/lang following positive vibes expressed here, I'd like to land this PR as a first step to implement the plan from that issue. Can we get this FCPd? :)

The one potential open question here is whether this should be a regular FCW first or whether it can immediately become an FCW that shows up in dependencies. I assume stdcall and fastcall are sufficiently rare that we can go for report-in-deps immediately (since they already get rejected on non-x86-32 non-Windows targets). "cdecl" might be more widely used though so it may be worth ramping up the lint more slowly.

@RalfJung RalfJung added the I-lang-nominated Nominated for discussion during a lang team meeting. label May 23, 2025
@traviscross traviscross added P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 23, 2025
@traviscross
Copy link
Contributor

Searching across GitHub, there are 506 Rust file hits on extern "cdecl".

Regarding whether to fire the FCW in deps immediately, I lean toward it probably being OK. Given that this may show up in cfg-heavy code, I could imagine that many library authors may not notice until their downstreams report anyway. But if anyone on lang feels we should walk this more slowly, that's what I'd estimate we'd do, so I'm curious to hear what others think.

@RalfJung
Copy link
Member Author

Oh that's the syntax for doing such a search... I tried and failed to get a similar result out of github search.^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants