Handling of stdcall (and other x86-32-specific ABIs) on non-x86-32 Windows targets is inconsistent

[RalfJung]

This is a tracking issue for the unsupported_calling_conventions lint. This lint warns against

• Using extern "cdecl" on non-x86-32 targets. Use extern "C" instead, there is no difference in behavior.
• Using extern "stdcall" or extern "fastcall" on non-x86-32 Windows targets. These ABIs are only defined for x86-32.
  • If you want to use "stdcall on x86-32-windows, C everywhere else", then use extern "system".
  • Otherwise, if you really need the same function both on x86-32 and on other targets but with a different ABI, consider using the fn_abi crate. Also we'd be interested to hear about your use-case, so please leave a comment below.

Implementation history:

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

Original issue description

We generally accept stdcall on non-x86-32 Windows targets (while rejecting it on other non-x86-32 targets). See the discussion about this at #86231 (comment) and #86231 (comment). However, @ChrisDenton points out that the raw-dylib feature is more strict here. That's an inconsistency that we should probably fix?

@ChrisDenton can you give an example of what exactly is being rejected by raw-dylib here?

2025-05-05: See here for the current latest proposal.

Cc @workingjubilee @rust-lang/lang @nagisa @petrochenkov

[ChrisDenton]

It's just generally more strict. As far as I recall this is intentional, cc @dpaoliello. For example:

#[link(name = "library", kind = "raw-dylib")]
extern "cdecl" { // or stdcall
    fn test();
}

This is rejected on x86_64-pc-windows-msvc and aarch64-pc-windows-msvc. But remove kind = "raw-dylib" and it works.

[RalfJung]

I think we should make up our mind: either "stdcall" is a legal ABI string on these targets, or it is not.

[Aditya-PS-05]

@rustbot claim

[RalfJung]

@Aditya-PS-05 currently this issue is about discussing what to do next; there is no agreed-upon plan for what to do yet.

---

Reading the past comments, it seems like ~noone argued in favor of the status quo. So maybe the best next step is to have a FCW lint against

• stdcall, fastcall on everything but 32-bit x86
• vectorcall on everything but x86 (32bit or 64bit)
• EDIT: cdecl on everything but 32-bit x86

This should probably re-introduce the lint that was removed in #129935.

@ChrisDenton also mentioned cdecl above; I did not have that on my radar yet. Currently, that one is accepted everywhere. Which targets should it support?

Either way, raw-dylib shouldn't have its own "does this ABI make sense" logic (currently located here); it should call is_abi_supported like everything else. (But that function might return a three-state value to indicate "not really but for backwards compatibility we accept this in some cases; and raw-dylib can then make a hard error rather than an FCW for those.)

[Aditya-PS-05]

@RalfJung , I agree we should centralize the ABI validation in is_abi_supported rather than having separate logic in raw-dylib.

For implementation, what about having is_abi_supported return something like:

enum AbiSupport {
    Supported,
    Unsupported,
    LegacyAccepted, // For backwards compatibility cases
}

This would let us:

1. Consolidate validation logic in one place
2. Clearly distinguish between fully supported vs legacy-accepted cases
3. Enable raw-dylib to be stricter while maintaining compatibility elsewhere

Some open questions we should resolve:

• What's the right target support for cdecl?
• Should we stage this (validation logic first, then FCW lint)?
• What's the migration story for existing code?

[ChrisDenton]

I think any discussion of implementation changes is premature. Knowing the history here and the reasons behind those decisions is the first step.

[dpaoliello]

It's just generally more strict. As far as I recall this is intentional, cc @dpaoliello.

Yes, it was intentional, although I would describe it more as "let's start restrictive and we'll loosen things later" rather than "this is the absolute correct behavior": #86419 (comment)

Either way, raw-dylib shouldn't have its own "does this ABI make sense" logic (currently located here); it should call is_abi_supported like everything else.

raw-dylib has its own logic for historical reasons: primarily that it wasn't supported for all calling conventions or all arches for a while, hence its own logic to filter to what it did support.

Personally, I'm going to bow out of this discussion. I previously said that having this behavior would cause a proliferation of cfg_attr attributes without a huge benefit to safety or correctness but was told that #87678 would eventually be an error and so this would be moot: https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Add.20import_name_type.20parameter.20to.20.23.5Blink.5D.20compiler-team.23525