stabilize c-style varargs for system, sysv64, win64, efiapi, aapcs

[RalfJung]

This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates.

The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a consensus has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR):

• "stdcall" for win32 targets for non-variadic functions
• "C" for everything else

This had been previously stabilized without FCP in #116161, which got reverted in #136897. There was also a "fun" race condition involved with the system ABI being added to the list of variadic-supporting ABIs between the creation and merge of #116161.

There was a question raised here whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me.

Fixes #100189, #136946
Cc @rust-lang/lang

Stabilization report

General design

What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?

AFAIK there is no RFC. The tracking issues are

• Tracking Issue for extended_varargs_abi_support #100189
• Tracking Issue for extern_system_varargs #136946

What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

The only controversial point is whether "system" ABI functions should support variadics.

• Pro: This allows crates like windows-rs to consistently use "system", see e.g. Should use extern "system" as much as possible microsoft/windows-rs#3626.
• Cons: @workingjubilee had some implementation concerns, but I think those have been resolved.

Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases.

Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?

Actually defining variadic functions in Rust remains unstable, under the c_variadic feature gate.

Has a Call for Testing period been conducted? If so, what feedback was received?

Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for #![feature(FEATURE_NAME)] and had N results".

There was no call for testing.

A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". THis doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics.

Implementation quality

All rustc does here is forward the ABI to LLVM so there's lot a lot to say here...

Summarize the major parts of the implementation and provide links into the code (or to PRs)

An example for async closures: https://rustc-dev-guide.rust-lang.org/coroutine-closures.html.

The check for allowed variadic ABIs is here.

The special handling of "system" is here.

Summarize existing test coverage of this feature

Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing.

Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time.

• What does the test coverage landscape for this feature look like?
  • Tests for compiler errors when you use the feature wrongly or make mistakes?
  • Tests for the feature itself:
    • Limits of the feature (so failing compilation)
    • Exercises of edge cases of the feature
    • Tests that checks the feature works as expected (where applicable, //@ run-pass).
  • Are there any intentional gaps in test coverage?

Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.).

This PR adds a codegen test ensuring we emit the correct LLVM IR: tests/codegen/cffi/c-variadic-ffi.rs.
There is an existing test ensuring that we keep rejecting variadics for ABIs where that is not supported (tests/ui/c-variadic/variadic-ffi-1.rs).

The test ensuring that we do not stabilize defining c-variadic functions is tests/ui/feature-gates/feature-gate-c_variadic.rs.

What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

None that I am aware of.

What FIXMEs are still in the code for that feature and why is it ok to leave them there?

None that I am aware of.

Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization

@Soveu added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, @beepster4096 added system. @workingjubilee recently refactored the ABI handling in the compiler, also affecting this feature.

Which tools need to be adjusted to support this feature. Has this work been done?

Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs.

Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here.

Type system and execution rules

What compilation-time checks are done that are needed to prevent undefined behavior?

(Be sure to link to tests demonstrating that these tests are being done.)

Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.

Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?

Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.

Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)

Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.

What updates are needed to the reference/specification? (link to PRs when they exist)

• update for more ABIs supporting c-variadics reference#1936

Common interactions

Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?

No.

What other unstable features may be exposed by this feature?

None.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
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]

HIR ty lowering was modified

cc @fmease

[Soveu]

Looks great :) Thanks for pushing this topic

[workingjubilee]

I drafted a PR of similar nature but halted on the fact that there are no tests that verify the functional correctness of code compiled with this feature. It is untested.

[workingjubilee]

@RalfJung I still wanted extern_system_varargs to be addressed separately, please.

[RalfJung]

That seems like a lot of unnecessary bureaucratic overhead to me and the two PRs would necessarily conflict. Why should it be separate?

[RalfJung]

Regarding test coverage -- checking the generated LLVM IR represents our usual level of coverage here. I agree it'd be great to have end-to-end tests that actually invoke C code, but we rarely ever do that, we don't have great infrastructure to do it, and I am not convinced that now is the time we have to start enforcing this.