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.

Co-authored-by: Ralf Jung <post@ralfj.de>

rustbot · 2026-01-29T22:06:17Z

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.

folkertdev · 2026-01-29T23:43:12Z

I believe I got everything

@rustbot ready

RalfJung

Next round of comments. Also, CI seems unhappy?

View changes since this review

RalfJung · 2026-01-31T11:08:59Z

compiler/rustc_const_eval/src/interpret/call.rs

+        // The check for the DefKind is so that we don't request the fn_sig of a closure.
+        // Otherwise, we hit:
+        //
+        // DefId(1:180 ~ std[269c]::rt::lang_start_internal::{closure#0}) does not have a "fn_sig"
+        let (fixed_count, callee_c_variadic_args) =
+            if matches!(self.tcx.def_kind(instance.def_id()), DefKind::Fn)
+                && let callee_fn_sig = self.tcx.fn_sig(instance.def_id()).skip_binder()
+                && callee_fn_sig.c_variadic()


This is very odd and seems to break our usual abstractions. How does codegen deal with this?

I'm not sure, I asked in #t-compiler/help > no `fn_sig`for `lang_start_internal` closure. My impression is that those functions just never get fn_sig called on them, but maybe there is some logic that I'm missing somewhere.

Apparently checking for the DefKind is fairly standard

RalfJung · 2026-01-31T11:10:03Z

compiler/rustc_const_eval/src/interpret/call.rs

+                // NOTE: this handles the extra caller location argument
+                // when `#[track_caller]` is used. This attribute is only allowed on `extern "Rust"`
+                // functions, so the c-variadic case does not need to handle the extra argument.
+                callee_fn_abi.args.iter().enumerate()


I don't understand this comment. How does this line do anything wrt track_caller?

this additional argument is not reflected in fixed_count

RalfJung · 2026-01-31T11:12:52Z

compiler/rustc_const_eval/src/interpret/stack.rs

+    pub(crate) fn allocate_varargs<I>(
+        &mut self,
+        caller_args: &mut I,
+    ) -> InterpResult<'tcx, VecDeque<MPlaceTy<'tcx, M::Provenance>>>
+    where
+        I: Iterator<Item = (&'a FnArg<'tcx, M::Provenance>, &'a ArgAbi<'tcx, Ty<'tcx>>)>,
+    {
+        // Consume the remaining arguments and store them in fresh allocations.
+        let mut varargs = Vec::new();
+        for (fn_arg, abi) in caller_args {
+            // FIXME: do we have to worry about in-place argument passing?
+            let op = self.copy_fn_arg(fn_arg);
+            let mplace = self.allocate(abi.layout, MemoryKind::Stack)?;
+            self.copy_op(&op, &mplace)?;
+
+            varargs.push(mplace);
+        }
+
+        // When the frame is dropped, these variable arguments are deallocated.
+        self.frame_mut().va_list = varargs.clone();
+
+        interp_ok(varargs.into())
+    }
+
+    fn deallocate_varargs(
+        &mut self,
+        varargs: &[MPlaceTy<'tcx, M::Provenance>],
+    ) -> InterpResult<'tcx> {


These two functions look symmetric, but they are very different: one implicitly works on the current frame, the other takes the vararg list as argument. Such a false symmetry is quite confusing.

Any ideas how to avoid that?

I moved the self.frame_mut().va_list = varargs.clone(); line out, so now the one allocates, the other deallocates. They both receive the variadic arguments as an argument actually.

compiler/rustc_const_eval/src/interpret/intrinsics.rs

RalfJung · 2026-01-31T11:18:30Z

src/tools/miri/tests/fail/c-variadic-mismatch-count.rs

+        let f = helper as *const ();
+        let f = std::mem::transmute::<_, unsafe extern "C" fn(...)>(f);
+
+        f();


Please pass an argument here so that the code looks more legit (it does pass the required number of arguments, just not in the right way)

RalfJung · 2026-01-31T11:19:51Z

compiler/rustc_const_eval/src/interpret/call.rs

+            } else {
+                // NOTE: this handles the extra caller location argument
+                // when `#[track_caller]` is used. This attribute is only allowed on `extern "Rust"`
+                // functions, so the c-variadic case does not need to handle the extra argument.


If this is relevant, it seems good to have an assertion double-checking this property.

RalfJung · 2026-01-31T11:23:08Z

@rustbot author

folkertdev · 2026-01-31T16:17:42Z

@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 and others added 9 commits January 29, 2026 21:53

add more miri tests

bba1abe

Apply suggestion from @RalfJung

d20c217

Co-authored-by: Ralf Jung <post@ralfj.de>

low-hanging fruit after review

f9dbc2c

consider the caller location argument

e0246b7

use transmute_copy

27f2fb1

split out allocate_varargs

7832e24

report UB when caller and callee signatures do not match

229f0cf

retrieve key field without the lang item

4bc2318

feature-gate c-variadic definitions and calls in const contexts

24b5666

folkertdev force-pushed the c-variadic-const-eval branch from e4bc4f9 to 8634e40 Compare January 29, 2026 22:06

This comment has been minimized.

Sign in to view

clean up feature gate

03543fb

folkertdev force-pushed the c-variadic-const-eval branch from 8634e40 to 03543fb Compare January 29, 2026 22:15

This comment has been minimized.

Sign in to view

folkertdev added 2 commits January 30, 2026 00:30

update tests

cc7d5b5

use vecdeque

5e6519c

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 Jan 29, 2026

This comment has been minimized.

Sign in to view

RalfJung reviewed Jan 31, 2026

View reviewed changes

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 31, 2026

changes after code review

49ba67a

folkertdev force-pushed the c-variadic-const-eval branch from 39af72b to 49ba67a Compare January 31, 2026 14:28

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 Jan 31, 2026

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

Uh oh!

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!

rustbot commented Jan 29, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

folkertdev commented Jan 29, 2026

Uh oh!

This comment has been minimized.

RalfJung 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!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jan 31, 2026

Uh oh!

folkertdev commented Jan 31, 2026

Uh oh!

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

RalfJung left a comment •

edited by rustbot

Loading