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

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)
- In particular, ensure we have all the UB documented. This includes the one for ABI compatibility: in particular, caller and callee must agree on whether the function is variadic and on the number of fixed arguments.
Stabilization PR (see instructions on forge) Stabilize c-variadic function definitions #155697
Reference PR add c-variadic function definitions reference#2177

Unresolved questions

Function pointers are not VaArgSafe #153646

passing `VaList` to `extern` functions

On linux calling foo will pass a sysv64 VaList to an extern "win64" function, which might be confusing.

extern "win64" {
    fn foo(_: VaList);
}

Resolved questions

Miri support

Has been added in #150601.

Continuing bikeshed on the ... syntax

There has been no discussion of a different syntax in recent years.

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.

The compiler internally determines that lifetime, to make sure that a VaList<'_> does not outlive the function that created it.

Ensure that even when this gets stabilized for regular functions, it is still rejected on const fn.

This is tested in https://github.com/rust-lang/rust/blob/main/tests/ui/parser/variadic-ffi-semantic-restrictions.rs and gives the following error:

error: functions cannot be both `const` and C-variadic
  --> $DIR/variadic-ffi-semantic-restrictions.rs:33:1
   |
LL | const unsafe extern "C" fn f4_1(x: isize, _: ...) {}
   | ^^^^^ `const` because of this             ^^^^^^ C-variadic because of this

We reject c-variadic async functions in a similar way.

Issue #125431

Poor interaction between NLL-borrowck, async, and c_variadic's ... desugaring (VaListImpl<'_>) #125431

The VaList definition introduced in #141980 circumvents this issue.

Issue #61275

Varargs are completely unchecked if passed as generics #61275

This is an issue with c-variadic calls, not with c-variadic definitons.

Issue #141618

VaList<'_> does not carry its ABI in its type #141618

We have some forwards-compatible ideas for how to potentially add the ABI to the type in the future. That is only required if we want to allow calling c-variadic functions with a non-system ABI. Because C only allows using the system ABI for c-variadic calls, that is unlikely to come up in practice.

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?

Variadic calls using the system ABI do not impose any additional constraints. We already handle some ABI compatibility issues using target modifiers.

Implementation history

va_arg codegen

VaList and its layout

other

c-variadic adjacent

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

@plietar

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.

@plietar

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

@plietar

@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).

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

@plietar

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

@plietar

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

A few questions:

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.
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.

@dlrobertson

@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.

I've been working on this for the past two week and have

Added va_list_kind to the target specification which closely mirrors clangs TargetInfo::BuiltinVaListKind
Added Type::va_list which builds the correct structure based on the targets va_list_kind

I'm struggling a bit with understanding how to write something in libcore and link that to Type::va_list in trans. I'm currently attempting to add #[lang = "va_list"] so that I can check the def.did against the lang_items().va_list_impl() id. Does this seem correct?

Also how would you like me to break this up into PRs? My current plan was to submit a PR once I got VaList implemented (meaning functions like vprintf could be defined and tested). Then submit a second PR for implementing support for functions like printf.

Rollup merge of rust-lang#160165 - folkertdev:reject-dotdotdot-post-e…

authz: FULL Rust flip — 3 TUs, 29 functions, $0.23, and no shim

Unrolled build for #160165

Rollup merge of #160165 - folkertdev:reject-dotdotdot-post-expansion,…

Auto merge of #141980 - beetrees:va-list-proposal, r=workingjubilee

Rollup merge of #158039 - folkertdev:c-variadic-lifetimes, r=RalfJung

feat(core): retro_environment command dispatch (P1.5)

Rollup merge of rust-lang#162905 - folkertdev:variadic-x86-windows-lo…

Unrolled build for #162905 in rollup 162989

Rollup merge of #162905 - folkertdev:variadic-x86-windows-lock-in, r=…

Navigation Menu

Repository navigation

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

Unresolved questions

passing `VaList` to `extern` functions

Resolved questions

Implementation history

399 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Unresolved questions

passing VaList to extern functions

Resolved questions

Implementation history

Activity

plietar commented on Sep 29, 2017

aturon commented on Sep 29, 2017

joshtriplett commented on Nov 23, 2017

thedataking commented on Feb 14, 2018

plietar commented on Feb 22, 2018

harpocrates commented on Mar 16, 2018

dlrobertson commented on Mar 20, 2018

nikomatsakis commented on Mar 20, 2018

dlrobertson commented on Apr 4, 2018

399 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

passing `VaList` to `extern` functions