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 · 2026-02-14T12:48:15Z

compiler/rustc_const_eval/src/interpret/intrinsics.rs

+                if arg_mplace.layout.ty != dest.layout.ty {
+                    throw_unsup_format!(
+                        "va_arg type mismatch: requested `{}`, but next argument is `{}`",
+                        dest.layout.ty,
+                        arg_mplace.layout.ty
+                    );
+                }


Here we do a type comparison, would it be more idiomatic to use layout_compat That would let through usize to u32/u64 conversions and I think pointer casts as well?

It is a bit less straightforward to describe than a simple equality though.

I would suggest to open an issue about this, and keep the most strict check for now. I am not entirely certain that layout_compat is enough.

Let's just go with the simple rule for now then.

folkertdev · 2026-02-14T12:53:28Z

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()


Nice, those changes look good to me.

folkertdev · 2026-02-14T13:54:35Z

CI made it, so, is this done?

RalfJung · 2026-02-14T14:37:13Z

Yes, please squash the history to something sensible :)

rustbot · 2026-02-14T16:23:23Z

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-02-14T17:49:36Z

Squashed it down into 6 commits, roughly by area of code that was touched.

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

folkertdev · 2026-02-15T17:15:12Z

@RalfJung a formality at this point but this needs your final (explicit) blessing

RalfJung · 2026-02-15T17:49:14Z

I'm aware, I just had plans this weekend that kept me away from my laptop. ;)

RalfJung · 2026-02-15T18:03:25Z

compiler/rustc_const_eval/src/errors.rs

+    #[primary_span]
+    pub span: Span,
+    pub kind: ConstContext,
+    pub non_or_conditionally: &'static str,


This field does not seem to be actually used? It showed up in the range-diff, seems to have been added during the rebase.

Right, I had to rebase over the changes to error messages/fluent. Not fun. Fixed this now.

RalfJung

(submitting a review to get a diff marker)

View changes since this review

RalfJung · 2026-02-16T07:48:02Z

Looks good, thanks for the patience!
@bors r+

rust-bors · 2026-02-16T07:48:05Z

📌 Commit 981dacc has been approved by RalfJung

It is now in the queue for this repository.

Rollup of 6 pull requests Successful merges: - #148206 (Deduplicated float tests and unified in floats/mod.rs) - #150601 (support c-variadic functions in `rustc_const_eval`) - #152103 (Consider captures to be used by closures that unwind) - #152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser) - #152648 (Remove timing assertion from `oneshot::send_before_recv_timeout`) - #152686 (bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`) Failed merges: - #152512 (core: Implement feature `float_exact_integer_constants`)

@RalfJung

Rollup merge of #150601 - folkertdev:c-variadic-const-eval, r=RalfJung support c-variadic functions in `rustc_const_eval` 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

Rollup of 6 pull requests Successful merges: - rust-lang/rust#148206 (Deduplicated float tests and unified in floats/mod.rs) - rust-lang/rust#150601 (support c-variadic functions in `rustc_const_eval`) - rust-lang/rust#152103 (Consider captures to be used by closures that unwind) - rust-lang/rust#152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser) - rust-lang/rust#152648 (Remove timing assertion from `oneshot::send_before_recv_timeout`) - rust-lang/rust#152686 (bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`) Failed merges: - rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`)

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 force-pushed the c-variadic-const-eval branch from fa8908e to 05768c3 Compare February 13, 2026 10:52

folkertdev commented Feb 14, 2026

View reviewed changes

folkertdev force-pushed the c-variadic-const-eval branch from 3c69b50 to 44c2b10 Compare February 14, 2026 16:23

This comment has been minimized.

Sign in to view

folkertdev added 5 commits February 14, 2026 22:26

allow const fn to be c-variadic

a7888c1

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

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

ce69380

c-variadic functions in rustc_const_eval

02c4af3

add c-variadic miri test

ca3d1a3

move va_list operations into InterpCx

f5bf335

folkertdev force-pushed the c-variadic-const-eval branch from 44c2b10 to f2e4a2f Compare February 14, 2026 21:55

RalfJung reviewed Feb 15, 2026

View reviewed changes

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

981dacc

folkertdev force-pushed the c-variadic-const-eval branch from f2e4a2f to 981dacc Compare February 15, 2026 18:54

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 16, 2026

jhpratt mentioned this pull request Feb 16, 2026

Rollup of 6 pull requests #152701

Merged

rust-bors bot merged commit 494c6da into rust-lang:main Feb 16, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Feb 16, 2026

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!

folkertdev Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

folkertdev Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

folkertdev Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

folkertdev Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

folkertdev commented Feb 14, 2026

Uh oh!

RalfJung commented Feb 14, 2026 via email

Uh oh!

rustbot commented Feb 14, 2026

Uh oh!

folkertdev commented Feb 14, 2026

Uh oh!

This comment has been minimized.

folkertdev commented Feb 15, 2026

Uh oh!

RalfJung commented Feb 15, 2026

Uh oh!

RalfJung Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

folkertdev Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

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!

RalfJung commented Feb 16, 2026

Uh oh!

rust-bors bot commented Feb 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

folkertdev commented Jan 2, 2026 •

edited

Loading

RalfJung left a comment •

edited by rustbot

Loading