support c-variadic functions in `rustc_const_eval` #150601

folkertdev · 2026-01-02T16:02:50Z

tracking issue: #44930

The new GlobalAlloc::VaList is used to create an AllocId that represents the variable argument list of a frame. The allocation itself does not store any data, all we need is the unique identifier.

The actual variable argument list is stored in Memory, and keyed by the AllocId. The Frame also stores this AllocId, so that when a frame is popped, it can deallocate the variable arguments.

At "runtime" a VaList value stores a pointer to the global allocation in its first bytes. The provenance on this pointer can be used to retrieve its AllocId, and the offset of the pointer is used to store the index of the next argument to read from the variable argument list.

Miri does not yet support va_arg, but I think that can be done separetely?

r? @RalfJung
cc @workingjubilee

rust-bors · 2026-01-04T20:20:19Z

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

rustbot · 2026-01-05T17:34:29Z

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

rust-bors · 2026-01-10T19:19:17Z

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

folkertdev

This'll need another rebase once the va_copy/va_end PR merges. I'm mostly wondering

whether things are in roughly the right place now
if the tests cover what you'd expect

View changes since this review

folkertdev · 2026-01-20T20:21:34Z

compiler/rustc_const_eval/src/interpret/intrinsics.rs

                self.float_muladd_intrinsic::<Quad>(args, dest, MulAddType::Nondeterministic)?
            }

+            sym::va_copy => {


this code looks kind of rough/unpolished, I'm probably just missing some convenient helpers.

folkertdev · 2026-01-20T20:23:51Z

tests/ui/consts/const-eval/c-variadic-fail.rs

+    const unsafe extern "C" fn helper(ap: ...) {
+        // A copy created using Clone is valid, and can be used to read arguments.
+        let mut copy = ap.clone();
+        assert!(copy.arg::<i32>() == 1i32);
+
+        let mut u = core::mem::MaybeUninit::uninit();
+        unsafe { core::ptr::copy_nonoverlapping(&ap, u.as_mut_ptr(), 1) };
+
+        // Manually creating the copy is fine.
+        let mut copy = unsafe { u.assume_init() };
+
+        // Using the copy is actually fine.
+        let _ = copy.arg::<i32>();
+        drop(copy);
+
+        // But then using the original is UB.
+        drop(ap);
+    }
+
+    const { unsafe { helper(1, 2, 3) } };
+    //~^ ERROR va_end on unknown va_list allocation ALLOC0 [E0080]


I believe this is what we discussed? A copy actually is fine, but using the copy and then the original (or vice versa) is UB.

RalfJung · 2026-01-20T20:24:54Z

tests/ui/consts/const-eval/c-variadic-fail.rs

+
+        // Using the copy is actually fine.
+        let _ = copy.arg::<i32>();
+        drop(copy);


Suggested change

drop(copy);

mem::forget(copy);

Does it still catch the UB if you avoid the double-drop?

It does, the copy.arg<i32>() deallocates the original allocation, so when the original gets dropped it's referencing a non-existent allocation and that gets reported. I'll add an additional test for it.

RalfJung · 2026-01-20T20:26:10Z

tests/ui/consts/const-eval/c-variadic-fail.rs

+        drop(copy);
+
+        // But then using the original is UB.
+        drop(ap);


The test that I expected would call va_arg on op again here, before dropping it. The va_arg should be UB because the iterator was already advanced via the copy.

I've also added a test now that first reads from the copy, and then from the original.

however `Drop` for `VaList` is not yet available in const fn

this does not detect UB yet when a `VaList` is copied manually

rustbot · 2026-01-21T09:52:16Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

RalfJung · 2026-01-21T16:23:51Z

compiler/rustc_const_eval/src/interpret/memory.rs

    /// Map for "extra" function pointers.
    extra_fn_ptr_map: FxIndexMap<AllocId, M::ExtraFnVal>,

+    pub(crate) va_list_map: FxIndexMap<AllocId, Vec<MPlaceTy<'tcx, M::Provenance>>>,


Oh I see, you have a separate map here to give "meaning" to a VaList allocation... that's the part I missed earlier.

If you have that... why do you even need the new variant in GlobalAlloc? I know I told you to add that, but I also didn't expect a va_list_map field. I like the idea with the field, but it's not clear to me that we need both the field and the new kind of GlobalAlloc.

An allocation is still needed to make the pointer. None of the other variants fit nicely I think, but maybe I'm just missing something?

A GlobalAlloc is only needed for global allocations, as the name suggests.

So, how should I get an AllocId then? something like this?

let (alloc_id, _, _) = { let f = self.layout_of(self.tcx.types.unit).unwrap(); let mplace = MPlaceTy::fake_alloc_zst(f); let ptr = mplace.ptr(); self.ptr_get_alloc_id(ptr, 0)? };

this specifically causes

pointer not dereferenceable: pointer must point to some allocation, but got 0x1[noalloc] which is a dangling pointer (it has no provenance)

Other approaches frustratingly create a Pointer instead of a Pointer:<M::Provemance>...

Your new va_list_map works basically like the existing extra_fn_ptr_map, so you can copy what we do for that:

rust/compiler/rustc_const_eval/src/interpret/memory.rs

Lines 221 to 222 in 7ec34de

let id = self.tcx.reserve_alloc_id();

let old = self.memory.extra_fn_ptr_map.insert(id, extra);

Also, please keep va_list_map private to this file and have methods similar to the existing special allocation kinds.

With the above, you still get a Pointer<CmseProvenance>. Other code uses global_root_pointer to turn that into a Pointer<M::Provenance>, but that fails when the pointer is not actually a global allocation. Function pointers would still use

pub enum GlobalAlloc<'tcx> { /// The alloc ID is used as a function pointer. Function { instance: Instance<'tcx> }, // ... }

I think?

ah, I found the assert that needs to change, nvm.

You will have to add a new variant to this enum and take that into account in Miri.

RalfJung · 2026-01-22T10:44:12Z

@rustbot author
Just so it is explicit when this is ready for review again :)

(I haven't yet had a chance to look at the code in detail, but given the larger structural issues it's probably better tog et those right before I do the detailed review.)

rustbot · 2026-01-22T10:44:17Z

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

folkertdev added A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) F-c_variadic `#![feature(c_variadic)]` labels Jan 2, 2026

rustbot assigned RalfJung Jan 2, 2026

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch from d30044f to 5f98625 Compare January 2, 2026 18:57

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch from 5f98625 to 3368321 Compare January 2, 2026 19:09

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch from 3368321 to 41a34bc Compare January 2, 2026 19:32

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch from 41a34bc to 8608ba7 Compare January 2, 2026 20:51

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch from 8608ba7 to 207b032 Compare January 2, 2026 21:58

folkertdev force-pushed the c-variadic-const-eval branch from 207b032 to 1794556 Compare January 5, 2026 10:30

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch 2 times, most recently from b297adc to c081ba3 Compare January 5, 2026 11:14

This comment has been minimized.

Sign in to view

folkertdev force-pushed the c-variadic-const-eval branch from c081ba3 to 293ba18 Compare January 5, 2026 12:25

folkertdev marked this pull request as ready for review January 5, 2026 17:34

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 5, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 5, 2026

folkertdev mentioned this pull request Jan 8, 2026

c_variadic: impl va_copy and va_end as Rust intrinsics #150436

Merged

folkertdev commented Jan 20, 2026

View reviewed changes

RalfJung reviewed Jan 20, 2026

View reviewed changes

folkertdev force-pushed the c-variadic-const-eval branch from 532c69e to 57c69f3 Compare January 20, 2026 20:25

RalfJung reviewed Jan 20, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

folkertdev added 11 commits January 21, 2026 10:51

add GlobalAlloc::VaList

7cfa4d7

allow const fn to be c-variadic

f237efc

however `Drop` for `VaList` is not yet available in const fn

make Va::arg and VaList::drop const fns

1651931

on call, split the standard and c-variadic arguments

ab1918f

set up VaList global storage

36759a2

implement va_arg in rustc_const_eval

ce45670

basic support for AllocKind::VaList in miri

2ca4269

add c-variadic const eval test

5d20e76

basic va_copy implementation

25e96ba

this does not detect UB yet when a `VaList` is copied manually

move over to the shared interpreter

c0ce0b0

more copy UB tests

9e57c73

folkertdev force-pushed the c-variadic-const-eval branch from 2763963 to 9e57c73 Compare January 21, 2026 09:52

RalfJung reviewed Jan 21, 2026

View reviewed changes

folkertdev added 2 commits January 22, 2026 10:37

stop using reserve_and_set_va_list_alloc

67aabb2

make va_list_map private

bdc0935

folkertdev force-pushed the c-variadic-const-eval branch 2 times, most recently from a3a75ad to 19347f2 Compare January 22, 2026 10:43

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

This comment has been minimized.

Sign in to view

remove GlobalAlloc::VaList again

83db12a

folkertdev force-pushed the c-variadic-const-eval branch from 19347f2 to 83db12a Compare January 22, 2026 11:07

	let id = self.tcx.reserve_alloc_id();
	let old = self.memory.extra_fn_ptr_map.insert(id, extra);

Uh oh!

support c-variadic functions in rustc_const_eval #150601

Are you sure you want to change the base?

support c-variadic functions in rustc_const_eval #150601

Conversation

folkertdev commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Jan 4, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Jan 5, 2026

Uh oh!

rust-bors bot commented Jan 10, 2026

Uh oh!

folkertdev left a comment • edited by rustbot 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!

RalfJung Jan 20, 2026 • 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!

This comment has been minimized.

rustbot commented Jan 21, 2026

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!

RalfJung Jan 22, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 22, 2026

Uh oh!

This comment has been minimized.

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

support c-variadic functions in `rustc_const_eval` #150601

support c-variadic functions in `rustc_const_eval` #150601

folkertdev commented Jan 2, 2026 •

edited

Loading

folkertdev left a comment •

edited by rustbot

Loading

RalfJung Jan 20, 2026 •

edited

Loading

RalfJung Jan 22, 2026 •

edited

Loading

RalfJung commented Jan 22, 2026 •

edited

Loading