Rework `c_variadic` #141980

beetrees · 2025-06-03T18:45:41Z

This is based on top of (and therefore blocked on) #144529.

On some platforms, the C va_list type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for va_list, the C standard explicitly states that it is undefined behaviour to use a va_list after it has been passed by value to a function (in Rust parlance, the va_list is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C va_list type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.

In the old implementation, this ABI was achieved by having two separate types: VaList was the type that needed to be used when passing a VaList as a function parameter, whereas VaListImpl was the actual va_list type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function void foo(va_list va) was equivalent to the Rust fn foo(va: VaList) whereas the C function void bar(va_list* va) was equivalent to the Rust fn foo(va: *mut VaListImpl), not fn foo(va: *mut VaList) as might be expected); also converting from VaListImpl to VaList with as_va_list() had platform specific behaviour: on single-element array of a struct platforms it would return a VaList referencing the original VaListImpl, whereas on other platforms it would return a cioy,

In this PR, there is now just a single VaList type (renamed from VaListImpl) which represents the C va_list type and will just work in all positions. Instead of having a separate type just to make the ABI work, #144529 adds a #[rustc_pass_indirectly_in_non_rustic_abis] attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the VaList rework, making use of the new attribute on all platforms where the C va_list type is a single-element array of a struct.

Cleanup of the VaList API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling va_end is not undefined behaviour (#141524 (comment)), I've removed the with_copy method as it was redundant to the Clone impl (the Drop impl of VaList is a no-op as va_end is a no-op on all known platforms).

Previous discussion: #141524 and t-compiler > c_variadic API and ABI
Tracking issue: #44930
r? @joshtriplett

rustbot · 2025-06-03T18:45:46Z

This PR modifies run-make tests.

cc @jieyouxu

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

workingjubilee · 2025-06-13T22:06:31Z

compiler/rustc_abi/src/layout/ty.rs

    fn is_transparent(this: TyAndLayout<'a, Self>) -> bool;
+    /// Returns `true` if the type is always passed indirectly. Currently only
+    /// used for `VaList`s.
+    fn is_pass_indirectly(this: TyAndLayout<'a, Self>) -> bool;


I only see this as having an effect on x86-64 and aarch64, but doesn't the argument-passing algorithm already enforce this by making sure that VaList gets passed via Memory?

This method is only needed by the code in rustc_target::callconv to ensure that VaList gets PassMode::Indirect { on_stack: false, .. }. repr_options_of_def sets the PASS_INDIRECTLY ReprFlag for VaList when it needs to be passed indirectly for non-rustic ABIs, however there is no way to directly access ReprFlags from the calling convention code. There is already a method is_transparent on TyAbiInterface to expose the IS_TRANSPARENT ReprFlag, so I used a similar pattern to expose PASS_INDIRECTLY to the calling convention code. Without this method, the System V x86-64 ABI would pass VaList with PassMode::Indirect { on_stack: true, .. }.

And just to finish the thought: the difference is important (only) in an FFI context: a foreign extern "C" { fn(ap: VaList); } would expect ap to be passed as PassMode::Indirect { on_stack: false, .. }

huh, fascinating.

RalfJung · 2025-07-02T15:41:11Z

compiler/rustc_middle/src/ty/mod.rs

+        if self.is_lang_item(did.to_def_id(), LangItem::VaList)
+            && !flags.contains(ReprFlags::IS_TRANSPARENT)
+        {
+            flags.insert(ReprFlags::PASS_INDIRECTLY);
+        }


So randomly in the middle of repr_options_of_def we decide what the ABI for VaList will be? That's a disaster waiting to happen IMO, nobody will suspect ABI-relevant code here...

Also, in the discussion the argument was that this is necessary when va_list is an array -- but I can't see that reflected here at all. Given that the actual source of the issue is array decay, shouldn't we just fix the extern "C" logic so that it passes all arrays by-ptr (there different ways to do that, none of them pretty until #119183 are resolved), and then that'll do the right thing for array-based va_list by itself?

This is where the (very-ABI-affecting) IS_TRANSPARENT repr flag is set (based on the function attributes), so it seemed like the best place to put it. Having it as a repr flag seemed like the best way to communicate it to the code in rustc_target (the only place that needs to be aware of it), but it would be easy enough to do it another way if this way is sub-optimal. You're correct about this not actually checking whether it is an array type: this was the easiest way to differentiate between the two types of array list when I was prototyping this, but it should be replaced with a more precise check. Passing all arrays by reference seems to have been discussed on Zulip and in the parent issue; I think it would be a footgun as C allows the user to observe modifications the callee makes to the array in the caller (unlike va_list, where the C standard says that using the va_list after passing it to a function is UB).

I think @folkertdev has suggested before something along the lines of a #[rustc_always_pass_indirectly] attribute which could be applied to VaList type as needed: would that be preferable?

Yeah I think if we do go for this (which I am not convinced we should), then it should be its own attribute, not magically connected to the lang item.

After more discussions on Zulip, I am convinced this is worth the experiment -- after being adjusted as proposed above: having a separate attribute. The compiler shouldn't tie rustc_always_pass_indirectly to varargs in any way.

That should also make it much easier to write tests just for this attribute. Ideally that's a separate PR from actually using it for varargs -- maye splitting it up is too much work (separate commits would still be good); but at the very least, we should have separate tests.

beetrees · 2025-07-03T19:34:27Z

when I run this PR locally, on x86_64, ./x test --keep-stage 1 tests/run-make/c-link-to-rust-va-list-fn fails.

I've just ran ./x test tests/run-make/c-link-to-rust-va-list-fn locally and it passed. Maybe --keep-stage 1 is messing things up? If someone runs an @bors try we could check if it passes in CI.

When I diff by_value and by_reference, they are very different while I suspected them to be the same.

I ran the assembly test you supplied locally and got this assembly:

Test assembly

	.file	"temp.9a048525d681a25f-cgu.0"
	.section	.text.by_reference,"ax",@progbits
	.globl	by_reference
	.p2align	4
	.type	by_reference,@function
by_reference:
	.cfi_startproc
	movl	(%rdi), %ecx
	cmpq	$40, %rcx
	ja	.LBB0_2
	movq	%rcx, %rax
	addq	16(%rdi), %rax
	addl	$8, %ecx
	movl	%ecx, (%rdi)
	movl	(%rax), %eax
	retq
.LBB0_2:
	movq	8(%rdi), %rax
	leaq	8(%rax), %rcx
	movq	%rcx, 8(%rdi)
	movl	(%rax), %eax
	retq
.Lfunc_end0:
	.size	by_reference, .Lfunc_end0-by_reference
	.cfi_endproc

	.section	.text.dummy,"ax",@progbits
	.globl	dummy
	.p2align	4
	.type	dummy,@function
dummy:
	.cfi_startproc
	retq
.Lfunc_end1:
	.size	dummy, .Lfunc_end1-dummy
	.cfi_endproc

	.globl	by_value
	.type	by_value,@function
.set by_value, by_reference
	.ident	"rustc version 1.89.0-dev"
	.section	".note.GNU-stack","",@progbits

LLVM appears to have merged the functions as they had identical assembly.

Over in #t-compiler > array-to-pointer decay npopov also mentions that on_stack: false is still distinct from array-to-pointer decay (though perhaps it's not meaningful for c_variadic.

on_stack: false does differ from array-to-pointer decay, but none of the differences matter for this particular use case as VaList is not Copy and C doesn't allow using a va_list after passing it as a function argument.

RalfJung · 2025-07-03T19:37:49Z

on_stack: false does differ from array-to-pointer decay, but none of the differences matter for this particular use case as VaList is not Copy and C doesn't allow using a va_list after passing it as a function argument.

I am somewhat uncomfortable relying on that, and would personally prefer a slightly less slick API that requires fewer hacks. This feature is too niche to justify so much hackery, IMO.

But maybe I am overly paranoid. If we do end up going for it, please add walls of comments everywhere that explain this, or else we can be sure some poor compiler contributor will spend hours digging through this in a few years...

folkertdev · 2025-07-03T19:39:30Z

@beetrees hmm, I did rebase, maybe that messed something up? Can you rebase this branch to something more recent?

beetrees · 2025-07-03T20:30:51Z

I've rebased, and the two tests still pass locally.

folkertdev · 2025-07-03T20:41:52Z

For me too, I must have messed something up earlier. Thanks for checking!

beetrees · 2025-07-04T19:35:11Z

I've reworked this to use a #[rustc_pass_indirectly_in_non_rustic_abis] attribute, which I've implemented independently in a separate commit.

rustbot · 2025-07-04T22:01:31Z

joshtriplett is not on the review rotation at the moment.
They may take a while to respond.

rustbot · 2025-07-06T14:54:37Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

folkertdev · 2025-07-06T16:15:13Z

library/core/src/ffi/va_list.rs

        /// Basic implementation of a `va_list`.
        #[repr(transparent)]
        #[lang = "va_list"]
-        pub struct VaListImpl<'f> {
+        pub struct VaList<'f> {
            ptr: *mut c_void,

-            // Invariant over `'f`, so each `VaListImpl<'f>` object is tied to
+            // Invariant over `'f`, so each `VaList<'f>` object is tied to
            // the region of the function it's defined in
            _marker: PhantomInvariantLifetime<'f>,
        }


Now that we're changing the representation, is PhantomInvariantLifetime still the right constraint on that lifetime? I believe it was chosen for consistency with the other representation, because it is the variance of 'a in &mut &'a mut T.

But now, the *mut fields in the various VaList definitions are morally just &mut references I think, so then maybe the variance should be covariant?

I'll admit I don't fully understand how variance works or what the consequences are, this is just what I take away from https://doc.rust-lang.org/nomicon/subtyping.html#variance.

#t-libs > variance of `VaList` agrees that Covariant is right.

Also, those pointer fields could be *const _ no mutations happen through it (it's just the field that gets updated).

folkertdev · 2025-07-06T16:18:42Z

library/core/src/ffi/va_list.rs

    // In this implementation the `va_list` type is just an alias for an opaque pointer.
    // That pointer is probably just the next variadic argument on the caller's stack.
    _ => {
        /// Basic implementation of a `va_list`.


I don't think this is urgent, but the comments on the VaList definitions should probably be consistent and not show implementation details? We can put a doc comment in an external file and include_str! it to prevent duplication.

I've added a #[repr(transparent)] wrapper struct that has the documentation attached.

folkertdev · 2025-07-06T16:19:30Z

library/core/src/ffi/va_list.rs

-        impl<'f> fmt::Debug for VaListImpl<'f> {
+        impl<'f> fmt::Debug for VaList<'f> {
            fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
-                write!(f, "va_list* {:p}", self.ptr)
+                f.debug_tuple("VaList").field(&self.ptr).finish()


Debug is derived for all the other implementations, we can do that here too now right?

bors · 2025-07-06T20:54:39Z

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

rustbot · 2025-07-27T03:33:27Z

Some changes occurred in src/tools/compiletest

cc @jieyouxu

beetrees · 2025-07-27T03:35:06Z

Feedback addressed and rebased due to conflicts.

@rustbot review

RalfJung · 2025-07-27T09:25:58Z

This PR right now adds a new compiler feature and also has a big chunk of libs changes. Might be worth splitting up? Otherwise it'll turn into a complicated multi-reviewer situation to ensure we have both parts covered.

beetrees · 2025-07-27T10:56:40Z

I've split adding #[rustc_pass_indirectly_in_non_rustic_abis] into #144529, and left the compiler cleanup for a follow-up PR. This PR is now library changes only (with the exception of a comment update).

@rustbot label +S-blocked -T-compiler

bors · 2025-07-30T12:54:43Z

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

beetrees marked this pull request as draft June 3, 2025 18:45

beetrees mentioned this pull request Jun 3, 2025

Consider folkertdev's c_variadic proposal #141524

Open

beetrees force-pushed the va-list-proposal branch from cb90479 to 23a983d Compare June 3, 2025 19:04

workingjubilee reviewed Jun 13, 2025

View reviewed changes

RalfJung reviewed Jul 2, 2025

View reviewed changes

This comment was marked as outdated.

Sign in to view

beetrees force-pushed the va-list-proposal branch from 23a983d to 57bc996 Compare July 3, 2025 20:30

beetrees force-pushed the va-list-proposal branch from 57bc996 to 6347a21 Compare July 4, 2025 19:26

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Jul 4, 2025

beetrees force-pushed the va-list-proposal branch from 6347a21 to 6e1e74f Compare July 4, 2025 19:34

beetrees changed the title ~~Prototype VaList proposal~~ Rework c_variadic Jul 4, 2025

This comment has been minimized.

Sign in to view

beetrees force-pushed the va-list-proposal branch from 6e1e74f to 26f7025 Compare July 4, 2025 19:52

beetrees closed this Jul 4, 2025

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 4, 2025

beetrees reopened this Jul 4, 2025

beetrees force-pushed the va-list-proposal branch from 26f7025 to 79a6396 Compare July 4, 2025 21:25

rustbot assigned joshtriplett Jul 4, 2025

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 6, 2025

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 6, 2025

This comment has been minimized.

Sign in to view

folkertdev reviewed Jul 6, 2025

View reviewed changes

Add #[rustc_pass_indirectly_in_non_rustic_abis]

c0357c1

beetrees force-pushed the va-list-proposal branch from 2bb2fc9 to 31aee4b Compare July 27, 2025 03:33

rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 27, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 27, 2025

beetrees mentioned this pull request Jul 27, 2025

Add #[rustc_pass_indirectly_in_non_rustic_abis] #144529

Open

beetrees force-pushed the va-list-proposal branch from 31aee4b to 050ee8a Compare July 27, 2025 10:54

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 27, 2025

This comment has been minimized.

Sign in to view

beetrees force-pushed the va-list-proposal branch from 050ee8a to 3d5e0ce Compare July 27, 2025 16:30

Rework c_variadic

ca9c162

beetrees force-pushed the va-list-proposal branch from 3d5e0ce to ca9c162 Compare July 27, 2025 16:31

folkertdev added the F-c_variadic `#![feature(c_variadic)]` label Sep 9, 2025

Dylan-DPC removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 22, 2025

Rework c_variadic #141980

Are you sure you want to change the base?

Rework c_variadic #141980

Uh oh!

Conversation

beetrees commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jun 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

beetrees commented Jul 3, 2025

Uh oh!

RalfJung commented Jul 3, 2025

Uh oh!

folkertdev commented Jul 3, 2025

Uh oh!

beetrees commented Jul 3, 2025

Uh oh!

folkertdev commented Jul 3, 2025

Uh oh!

beetrees commented Jul 4, 2025

Uh oh!

This comment has been minimized.

rustbot commented Jul 4, 2025

Uh oh!

rustbot commented Jul 6, 2025

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Jul 6, 2025

Uh oh!

rustbot commented Jul 27, 2025

Uh oh!

beetrees commented Jul 27, 2025

Uh oh!

RalfJung commented Jul 27, 2025

Uh oh!

beetrees commented Jul 27, 2025

Uh oh!

This comment has been minimized.

bors commented Jul 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Rework `c_variadic` #141980

Rework `c_variadic` #141980

beetrees commented Jun 3, 2025 •

edited

Loading

workingjubilee Jun 15, 2025 •

edited

Loading

RalfJung Jul 4, 2025 •

edited

Loading