Skip to content

Conversation

@folkertdev
Copy link
Contributor

@folkertdev folkertdev commented Jan 2, 2026

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

@folkertdev 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 rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 2, 2026
@rust-log-analyzer

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

rust-bors bot commented Jan 4, 2026

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

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

This comment has been minimized.

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

This comment has been minimized.

@folkertdev folkertdev force-pushed the c-variadic-const-eval branch from c081ba3 to 293ba18 Compare January 5, 2026 12:25
@folkertdev folkertdev marked this pull request as ready for review January 5, 2026 17:34
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 5, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 5, 2026

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

@rustbot 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
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 10, 2026

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

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

RalfJung commented Jan 22, 2026

@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 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
@rustbot
Copy link
Collaborator

rustbot commented Jan 22, 2026

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

@rust-log-analyzer

This comment has been minimized.

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

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I know why the provenance is being lost...

On x86, VaListInner is declared as starting with 8 integer bytes. We are storing pointer data there. When copying the VaListInner, that will drop the provenance.

What's less clear to me is where a VaList (and therefore its inner field) is being copied. But given that we expose this type to users I guess it is expected that they are allowed to copy it...

It seems like currently, all VaListInner types have a pointer field that we could use to store the pointer that the interpreter uses to represent the actual state. Not sure if that's a safe thing to bet on though...

View changes since this review

this.dedup_diagnostic(&DEDUP, |first| {
NonHaltingDiagnostic::Int2Ptr { details: first }
this.dedup_diagnostic(&DEDUP, |first| NonHaltingDiagnostic::Int2Ptr {
details: first,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some odd reformatting happening here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, ./x fmt is happy with it though

Copy link
Member

@RalfJung RalfJung Jan 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

./x fmt skips Miri files. Miri has its own rustfmt.toml so if your editor is set up incorrectly then reformatting in the editor might end up using the rustc rustfmt.toml rather than Miri's config and thus result in spurious changes.

self.deallocate_ptr(ptr, None, MemoryKind::Stack)?;

interp_ok(())
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The corresponding allocation code for this is super far away in a different file -- that's not great.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, though the allocation is just self.allocate. I could extract that into a method?

Copy link
Contributor Author

@folkertdev folkertdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're getting somewhere, that deref suggestion was really helpful.

View changes since this review

this.dedup_diagnostic(&DEDUP, |first| {
NonHaltingDiagnostic::Int2Ptr { details: first }
this.dedup_diagnostic(&DEDUP, |first| NonHaltingDiagnostic::Int2Ptr {
details: first,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, ./x fmt is happy with it though

self.deallocate_ptr(ptr, None, MemoryKind::Stack)?;

interp_ok(())
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, though the allocation is just self.allocate. I could extract that into a method?

@folkertdev
Copy link
Contributor Author

And I'm now looking up a pointer field in the VaList, so Miri works again. I think it's fine to assume at least one field will be a pointer, if need be we can do some cfg(miri) stuff in the definition if we do run into a really weird target at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. F-c_variadic `#![feature(c_variadic)]` S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants