Enable varargs support for calling conventions other than C or cdecl

[Soveu]

This patch makes it possible to use varargs for calling conventions,
which are either based on C (efiapi) or C is based on them (sysv64 and win64).

Also pinging @phlopsi, because he noticed first this oversight when writing a library for UEFI.

[rust-highfive]

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

[rust-highfive]

r? @jackh726

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

[rust-highfive]

⚠️ Warning ⚠️

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

[jackh726]

I'm going to ping @rust-lang/lang and @rust-lang/compiler for this, since it's technically an insta-stable language feature.

[jackh726]

I think this needs lang FCP, maybe compiler FCP too.

[scottmcm]

Does this need to go in insta-stable?

My default lang-hat answer for these things is that it should go in feature-gated first, so it just needs a compiler r+ right now and stabilization is a question for later.

[pnkfelix]

@Soveu I think at this point we want this change to be guarded by a feature gate.

You can see documentation in the rustc-dev-guide on how to introduce and use such guards in the rustc source code. Specifically:

• https://rustc-dev-guide.rust-lang.org/feature-gates.html
• https://rustc-dev-guide.rust-lang.org/implementing_new_features.html#stability-in-code

@jackh726 has agreed to help mentor with whatever help you need to make the necessary changes here.

[Soveu]

While I have still access to my laptop that can definitely build rustc, I think I made most of the changes required for proper feature gating.

A tracking issue still has to be created, at least that can be done from any device.
Is a full RFC needed for this change though?

[jackh726]

Doesn't need an RFC (certainly not for unstable - someone might ask for it for stabilization, but I doubt it)

From quickly skimming, I think I'd like to see each of the new abis in a test under the feature and without the feature.

[estebank]

Nitpick: ideally we'd provide a structured suggestion that makes it explicit where and what to change:

error[E0045]: C-variadic function must have a compatible calling convention
  --> $DIR/variadic-ffi-1.rs:9:5
   |
LL |   extern "stdcall" {
   |           ------- this calling convention is not valid for C-variadic functions
LL |     fn printf(_: *const u8, ...);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^---^^ C-variadic function must have a compatible calling convention
   |
help: declare the `extern` block with a compatible calling convention
   |
LL |   extern "C" {
   |           ~
LL |   extern "cdecl" {
   |           ~~~~~

[estebank]

And this would look like

error[E0045]: C-variadic function must have a compatible calling convention
   --> $DIR/variadic-ffi-2.rs:4:11
    |
 LL | fn baz(f: extern "stdcall" fn(usize, ...)) {
    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ C-variadic function must have a compatible calling convention
help: declare the type with a compatible calling convention
   |
 LL | fn baz(f: extern "C" fn(usize, ...)) {
    |                   ~
 LL | fn baz(f: extern "cdecl" fn(usize, ...)) {
    |                   ~~~~~
 LL | fn baz(f: extern "win64" fn(usize, ...)) {
    |                   ~~~~~
 LL | fn baz(f: extern "sysv64" fn(usize, ...)) {
    |                   ~~~~~~
 LL | fn baz(f: extern "efiapi" fn(usize, ...)) {
    |                   ~~~~~~

[apiraino]

This PR has been discussed by T-compiler on Zulip (meetings' notes). I think I can switch the labels. Please feel free to switch back when a new review is needed, thanks.

@rustbot author

[jackh726]

Need to file a tracking issue, and I'd like to see all the relevant abis show up in the tests.

Other than that, LGTM. I think this is "rare" enough that we don't need to be nitpicky about diagnostics here.

[Soveu]

Soooo, I was pretty busy last week or two, but I should have some time this weekend.

[Soveu]

@rustbot review

[jackh726]

Version change, then can you squash commits? All good after that.

[bors]

☔ The latest upstream changes (presumably #102306) made this pull request unmergeable. Please resolve the merge conflicts.

[jackh726]

Updated message and rebased.

@bors r+

[bors]

📌 Commit de78c32 has been approved by jackh726

It is now in the queue for this repository.