`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics by folkertdev · Pull Request #150436 · rust-lang/rust

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

folkertdev · 2025-12-27T16:20:33Z

tracking issue: #44930

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.

Discussed in #t-compiler/const-eval > c-variadics in const-eval.

I've also updated the comment for Drop a bit. The background here is that the C standard requires that va_end is used in the same function (and really, in the same scope) as the corresponding va_start or va_copy. That is because historically va_start would start a scope, which va_end would then close. e.g.

https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol

#defineva_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#defineva_end(ap) }
#defineva_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))

The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use Clone for va_copy and Drop for va_end.

folkertdev · 2025-12-27T16:21:09Z

 /// Basic implementation of a `va_list`.
 #[repr(transparent)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]
 struct VaListInner {
 ptr: *const c_void,
 }


https://github.com/llvm/llvm-project/blob/87e8e7d8f0db53060ef2f6ef4ab612fc0f2b4490/llvm/lib/Transforms/IPO/ExpandVariadics.cpp#L127-L129

folkertdev · 2025-12-27T16:21:34Z

 /// https://github.com/llvm/llvm-project/blob/0cdc1b6dd4a870fc41d4b15ad97e0001882aba58/clang/lib/CodeGen/Targets/Hexagon.cpp#L407-L417
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp#L1087

folkertdev · 2025-12-27T16:21:47Z

 /// https://github.com/llvm/llvm-project/blob/af9a4263a1a209953a1d339ef781a954e31268ff/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1211-L1215
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp#L1260

folkertdev · 2025-12-27T16:23:59Z

 /// https://docs.google.com/gview?embedded=true&url=https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/SystemZ/SystemZISelLowering.h#L339

folkertdev · 2025-12-27T16:24:20Z

 /// [GCC header]: https://web.mit.edu/darwin/src/modules/gcc/gcc/ginclude/va-ppc.h
 #[repr(C)]
- #[derive(Debug)]
+ #[derive(Debug, Clone, Copy)]


https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713

folkertdev · 2026-01-02T21:04:28Z

r? @workingjubilee

The codegen of VaList::clone is target-specific now, and because minicore does not define VaList it is hard to test. I think it's fine to just test the behavior, and have LLVM use a memcpy when VaList is a struct, or just re-use the pointer value if it's just a pointer.

rustbot · 2026-01-02T21:04:33Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-01-02T21:04:34Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

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

RalfJung · 2026-01-03T15:13:28Z

Implement va_copy as (the rust equivalent of) memcpy, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior.

Didn't we say we would avoid that assumption and also support implementations that do malloc/free in va_copy / va_end? See #t-compiler/const-eval > c-variadics in const-eval @ 💬.

folkertdev · 2026-01-03T23:53:02Z

That's right, we don't actually impl Copy for VaList, so that a future target could implement a meaningful Clone and Drop. It's just that in practice for all current targets Clone happens to be a memcpy and Drop a no-op

workingjubilee

Offering a suggested historical note.

Please feel free to trim it or move it into the PR description itself, down to the amounts you find worthwhile or just amusing to keep (including 0 lines).

r=me after

Thanks!

View changes since this review

RalfJung · 2026-01-07T07:57:19Z

@folkertdev what is your plan for va_copy regarding the const-eval support for this?
ISTM that without the intrinsic, it'll not be possible to catch a bunch of the UB that we had planned to catch?

folkertdev · 2026-01-07T20:19:22Z

Based on further discussion in #t-compiler/const-eval > c-variadics in const-eval, a slight change of plans

we still no longer call LLVM's va_copy
we do still have our own va_copy intrinsic that serves as a hook for const evaluation
va_copy has a fallback body, code generation backends should not provide their own implementation

I've changed the signature of the intrinsic to be more ergonomic, and made it safe because while the hook is used to detect UB, the intrinsic itself is completely safe.

RalfJung · 2026-01-19T19:58:04Z

 ///
 /// See the [LLVM source] and [GCC header] for more details.
 ///
+ /// `va_copy` is `memcpy`: <https://github.com/llvm/llvm-project/blob/5aee01a3df011e660f26660bc30a8c94a1651d8e/llvm/lib/Target/PowerPC/PPCISelLowering.h#L713>


This is also just a header, not the implementation? (same for some of the other ones)

Ah now I understand what happened: i copied these links from a github search result page. I manually looked them all up now, so all links should be correct.

RalfJung · 2026-01-20T17:35:49Z

Sounds great, thanks! r=workingjubilee,RalfJung with the last commit squashed away.

@bors delegate+

rust-bors · 2026-01-20T17:35:52Z

✌️ @folkertdev, you can now approve this pull request!

If @RalfJung told you to "r=me" after making some further change, then please make that change and post @bors r=RalfJung.

folkertdev · 2026-01-20T19:16:43Z

@bors r=workingjubilee,RalfJung

rust-bors · 2026-01-20T19:16:47Z

📌 Commit 922057c has been approved by workingjubilee,RalfJung

It is now in the queue for this repository.

@ghost

Rollup of 6 pull requests Successful merges: - #150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - #151340 (Port `#[patchable_function_entry]` to attr parser) - #151351 (Deduplicate diagnostics for const trait supertraits) - #151424 (missing colon after the compile-flags directive) - #151428 (Port variance attrs to attr parser.) - #151429 (s390x: Support aligned stack datalayout) Failed merges: - #151343 (Port some crate level attrs to the attribute parser) r? @ghost

Rollup merge of #150436 - va-list-copy, r=workingjubilee,RalfJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: #44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

@ghost

Rollup of 6 pull requests Successful merges: - rust-lang/rust#150436 (`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics) - rust-lang/rust#151340 (Port `#[patchable_function_entry]` to attr parser) - rust-lang/rust#151351 (Deduplicate diagnostics for const trait supertraits) - rust-lang/rust#151424 (missing colon after the compile-flags directive) - rust-lang/rust#151428 (Port variance attrs to attr parser.) - rust-lang/rust#151429 (s390x: Support aligned stack datalayout) Failed merges: - rust-lang/rust#151343 (Port some crate level attrs to the attribute parser) r? @ghost

…fJung `c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics tracking issue: rust-lang#44930 Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval. Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704). I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g. https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol ```c #define va_start(ap, parmN) {\ va_buf _va;\ _vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN) #define va_end(ap) } #define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode))) ``` The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.

…comments, r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

Rollup merge of #160157 - beetrees:va-list-outdated-backend-comments, r=folkertdev Remove outdated comments from `va_list.rs` Since #150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

… r=folkertdev Remove outdated comments from `va_list.rs` Since rust-lang/rust#150436 codegen backends haven't needed to implement `va_copy` or `va_end` as they are implemented using intrinsic fallback bodies, so the comments on the `#[inline]` annotations are no longer relevant. I've left the `#[inline]` annotations themselves as they seem worthwhile since `va_copy` and `va_end` are a memcpy and a no-op respectively.

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 27, 2025

folkertdev commented Dec 27, 2025
View reviewed changes

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch 3 times, most recently from 7a78640 to 8e09112Compare January 2, 2026 21:02

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 2, 2026

rustbot assigned workingjubilee Jan 2, 2026

folkertdev marked this pull request as ready for review January 2, 2026 21:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 2, 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 2, 2026

workingjubilee approved these changes Jan 6, 2026
View reviewed changes

Comment threadlibrary/core/src/ffi/va_list.rs

workingjubilee 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 6, 2026

RalfJung reviewed Jan 7, 2026
View reviewed changes

Comment threadlibrary/core/src/intrinsics/mod.rs

folkertdev changed the title ~~c_variadic: use Clone instead of va_copy~~c_variadic: use Clone instead of LLVM va_copyJan 7, 2026

folkertdev force-pushed the va-list-copy branch from 8e09112 to 00673e0Compare January 7, 2026 20:15

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from 00673e0 to 19e7342Compare January 7, 2026 20:22

This comment has been minimized.
Sign in to view

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

This comment has been minimized.
Sign in to view

folkertdev force-pushed the va-list-copy branch from c2939bc to f6d7c93Compare January 19, 2026 18:41

RalfJung reviewed Jan 19, 2026
View reviewed changes

folkertdev force-pushed the va-list-copy branch 2 times, most recently from 94ce7b4 to 6011fa6Compare January 19, 2026 20:55

folkertdev added 2 commits January 20, 2026 18:38

c_variadic: use Clone instead of LLVM va_copy
dd9241d

c-variadic: make VaList::drop call the rust va_end
922057c

folkertdev force-pushed the va-list-copy branch from 6011fa6 to 922057cCompare January 20, 2026 17:39

rust-borsBot 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 Jan 20, 2026

jhpratt mentioned this pull request Jan 21, 2026
Rollup of 6 pull requests #151436
Merged

rust-borsBot merged commit 43d2006 into rust-lang:mainJan 21, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Jan 21, 2026

rust-timer mentioned this pull request Feb 19, 2026
Rollup of 18 pull requests #152825
Merged

beetrees mentioned this pull request Jul 29, 2026
Remove outdated comments from va_list.rs#160157
Merged

Uh oh!

Uh oh!

Conversation

folkertdev commented Dec 27, 2025• edited by workingjubilee Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

This comment has been minimized.

folkertdev commented Jan 2, 2026

Uh oh!

rustbot commented Jan 2, 2026

Uh oh!

rustbot commented Jan 2, 2026

Uh oh!

RalfJung commented Jan 3, 2026

Uh oh!

folkertdev commented Jan 3, 2026

Uh oh!

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

Uh oh!

RalfJung commented Jan 7, 2026

Uh oh!

Uh oh!

This comment has been minimized.

folkertdev commented Jan 7, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

RalfJungJan 19, 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!

RalfJung commented Jan 20, 2026

Uh oh!

rust-borsBot commented Jan 20, 2026

Uh oh!

folkertdev commented Jan 20, 2026

Uh oh!

rust-borsBot commented Jan 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

folkertdev commented Dec 27, 2025• edited by workingjubilee Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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

folkertdev commented Dec 27, 2025•
edited by workingjubilee
Loading

workingjubilee left a comment •
edited by rustbot
Loading

RalfJungJan 19, 2026•
edited
Loading

folkertdev commented Dec 27, 2025•
edited by workingjubilee
Loading

workingjubilee left a comment •
edited by rustbot
Loading

RalfJungJan 19, 2026•
edited
Loading