Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust (c_variadic)

[aturon]

This is a tracking issue for the RFC "Support defining C-compatible variadic functions in Rust" (rust-lang/rfcs#2137).

Steps:

• Implement the RFC (PR Support defining C compatible variadic functions #57760)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Continuing bikeshed on the ... syntax.
• What even is the semantics of this? What exactly is allowed and disallowed? Would be good to have a Miri implementation.
• borrowck problems: Poor interaction between NLL-borrowck, async, and c_variadic's ... desugaring (VaListImpl<'_>) #125431
• What exactly are the ABI requirements around variadic calls? What are the ABI compatibility rules? Do we have to be concerned about LLVM target features affecting variadic ABI?
• Soundness bug: Varargs are completely unchecked if passed as generics #61275
• VaList<'_> does not carry its ABI in its type #141618

Resolved questions:

• "When implementing this feature, we will need to determine whether the compiler
  can provide an appropriate lifetime that prevents a VaList from outliving its
  corresponding variadic function."
• Ensure that even when this gets stabilized for regular functions, it is still rejected on const fn.

Implementation history

va_arg codegen

• codegen: Fix va_list - aarch64 iOS/Windows #56599
• Properly define va_arg and va_list for aarch64-apple-darwin #78126
• implement va_arg for x86_64 systemv #141538
• implement va_arg for powerpc #141622
• use custom types to clarify arguments to emit_ptr_va_arg #141623
• match clang's va_arg assembly on arm targets #144549

VaList and its layout

• libcore: Add VaList and variadic arg handling intrinsics #49878
• tests: Simplify VaList run-make test #56396
• VaList::copy should not require a mutable ref #57311
• Support defining C compatible variadic functions #57760
• core: ensure VaList passes improper_ctypes lint #58938
• Fix segfaults in release build C-variadic fns #58985
• ffi: rename VaList::copy to VaList::with_copy #59371
• Refactor C FFI variadics to more closely match their C counterparts, and add Clone implementation #59625
• Make VaListImpl<'f> invariant over the 'f lifetime #62639
• Fix intra-docs link in core::ffi::VaList #77784
• Give VaList its own home #126921
• c_variadic: make VaList abi-compatible with C #141980

other

• Allow "C-unwind" fn to have C variadics #126843
• core: VaArgSafe is an unsafe trait #126927
• use cfg_select! to select the right VaListImpl definition #141361
• c_variadic: Add future-incompatibility warning for ... arguments without a pattern outside of extern blocks #143619
• Add #[rustc_pass_indirectly_in_non_rustic_abis] #144529
• improve c-variadic error reporting #146165
• Improve C-variadic error messages: part 2 #146342
• c-variadic: allow c-variadic inherent and trait methods #146434
• document core::ffi::VaArgSafe #146521
• implement feature(c_variadic_naked_functions) #148770
• c-variadic: bpf and spirv do not support c-variadic definitions #149557

c-variadic adjacent

• fix issue with cmse-nonsecure-entry ABI being both async and c-variadic #146551
• kcfi: only reify trait methods when dyn-compatible #146865

[plietar]

I'd like to work on this, I already have some prototype

[aturon]

Awesome @plietar! It'd probably be good to bring this up in the "middle-end" compiler working group channel, which would also be a good place to get any help you might need.

[joshtriplett]

@plietar How goes the implementation? I remember you showing a mostly complete prototype on IRC.

[thedataking]

@plietar any news to share? This is a blocker for teams working on C to Rust transpilers, so this addition would be very welcome. (I'm part of one such team).

[plietar]

Hey,
Sorry I've been busy and then forgot about this. I'll get my prototype back in shape, hopefully by this weekend.

[harpocrates]

@plietar Any update on this? Do you have a WIP branch I can check out to try / fiddle with this?

[dlrobertson]

Looks like I'm a little late to the party 😄 ... sorry about that

A few questions:

1. How would functions that use a va_list multiple times work without the ability to explicitly use va_start and va_end? Are they expected to use copy? E.g. execl typically loops through the arguments to to get argc, creats a array argv of size argc, loops through the list again populating argv, and finally call execv.

2. The structure of a va_list varies greatly between the architectures. The intrinsic functions work with the architecture specific structure bitcast to an i8*, but AFAIK we'll still need to define the structure. Which architectures will be expected to be supported in the first iteration? Or am I mistaken that we'll have to define the structure?

@plietar if you don't have the time to work on this any more or if there is any way I could help out, I'd be more than happy to do so. I haven't worked on rustc much, but I'd be happy to help however I can with the implementation of this.

[nikomatsakis]

@dlrobertson

Seems likely that @plietar doesn't have much time, though they can speak for themselves.

I've not really looked closely at what would be needed to implement this, but if you need any help, please ping me, or reach out on gitter/IRC.