Add `#[rustc_pass_indirectly_in_non_rustic_abis]` #144529

beetrees · 2025-07-27T10:40:17Z

This PR adds an internal #[rustc_pass_indirectly_in_non_rustic_abis] attribute that can be applied to structs. Structs marked with this attribute will always be passed using PassMode::Indirect { on_stack: false, .. } when being passed by value to functions with non-Rustic calling conventions. This is needed by #141980; see that PR for further details.

cc @joshtriplett

rustbot · 2025-07-27T10:40:23Z

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-07-27T10:40:25Z

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

RalfJung · 2025-07-27T16:40:45Z

compiler/rustc_target/src/callconv/amdgpu.rs

    Ty: TyAbiInterface<'a, C> + Copy,
    C: HasDataLayout,
 {
+    if arg.layout.pass_indirectly_in_non_rustic_abis(cx) {


If we rely on every single callconv getting this right, we're toast. It's way too easy to forget this somewhere.

Is there some way we can do this centrally for all ABIs?
For instance, we could apply this logic after the target-specific ABI stuff has been done.
Cc @workingjubilee

The individual calling conventions sometimes still need to be aware of the parameters, to update the number of remaining general-purpose registers, and the current design of the calling convention code makes it hard to abstract this. Separately from this PR, I've been planning to refactor the calling convention handling a bit as even without this change there's a lot of code duplication already (all the compute_abi_info functions are essentially variants of the same function with calls to classify_arg and classify_ret); this refactoring should make it possible to do this in a more centralised way.

For now, this PR previously had a cfg!(debug_assertions)-guarded check at the end of adjust_for_foreign_abi in callconv/mod.rs that asserts that individual calling convention correctly set all the #[rustc_pass_indirectly_in_non_rustic_abis] arguments to be passed indirectly. I've updated the check so it now always run rather than just running when debug_assetions are enabled.

The individual calling conventions sometimes still need to be aware of the parameters, to update the number of remaining general-purpose registers,

Urgh, right, I forgot we need to care about low-level nonsense like that here. :/

Regarding refactoring the ABI code, also see #119183. I think @workingjubilee also has some thoughts in that direction. I'm happy to discuss design options and provide feedback.

Not the most robust idea, but we there could be some kind of ICE-causing bomb that gets defused when checking an arg's pass_indirectly_in_non_rustic_abis and ignored if there are no args. This at least makes sure that new targets don't get very far if they miss this important detail.

Or a codegen test that gets run on all targets?

We have some code doing sanity checks on the ABI after it got computed. We could probably add an assertion there.

rust/compiler/rustc_ty_utils/src/abi.rs

Lines 368 to 372 in d71ed8d

fn fn_abi_sanity_check<'tcx>(

cx: &LayoutCx<'tcx>,

fn_abi: &FnAbi<'tcx, Ty<'tcx>>,

spec_abi: ExternAbi,

) {

The indirect_argument function would not be codegened if it doesn't get called, so that wouldn't trigger the ABI check. It should probably just be a ui test. This won't run in CI for tier 3 targets, but the worst that can happen is that you get an ICE, not a silent miscompilation.

How do we make sure that triggers for every ABI though?

It's an unstable attribute, so worst case we get an ICE when building libcore. That seems fine.

The indirect_argument function would not be codegened if it doesn't get called, so that wouldn't trigger the ABI check.

what if we use a const fn? Maybe using some const _: () = assert!(/* ... */), would that work?

Using const does work, I added that and a fix for transparent wrappers ignoring the attribute at master...folkertdev:rust:pass-indirectly-attr-updates

@beetrees feel free to steal or chery-pick from that. I'd also happily force-push to this branch if you don't have time/interest. (this is on the critical path for c-variadics now that the error messages are in a good state, and I'd hate to waste the reviewer momentum).

I've cherry-picked your patch for this.

RalfJung · 2025-07-27T20:28:44Z

@jdonszelmann could you have a look at the attribute code here? This is my first time actually seeing the new infrastructure so I can't say if the way it is used here is correct.

RalfJung

The compiler part LGTM apart from these comments, but I can't really review these ABI adjustments.

compiler/rustc_target/src/callconv/riscv.rs

compiler/rustc_target/src/callconv/x86_64.rs

bors · 2025-07-31T20:59:45Z

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

rustbot · 2025-08-01T01:43:28Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann

SparrowLii · 2025-08-04T01:26:48Z

r? @joshtriplett :)

rustbot · 2025-08-04T01:26:52Z

joshtriplett is not on the review rotation at the moment.
They may take a while to respond.

folkertdev · 2025-09-03T18:48:06Z

Besides Jubilee, who is not available, the only other person I can think of to review ABI code is

r? @bjorn3

bors · 2025-09-09T16:22:05Z

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

Add `#[rustc_pass_indirectly_in_non_rustic_abis]` This PR adds an internal `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute that can be applied to structs. Structs marked with this attribute will always be passed using `PassMode::Indirect { on_stack: false, .. }` when being passed by value to functions with non-Rustic calling conventions. This is needed by #141980; see that PR for further details. cc `@joshtriplett`

bors · 2025-11-04T12:05:40Z

⌛ Testing commit 7be6d6f with merge a9b8649...

Zalathar · 2025-11-04T12:08:00Z

Yielding to enclosing rollup.

@bors retry

Rollup of 4 pull requests Successful merges: - #144529 (Add `#[rustc_pass_indirectly_in_non_rustic_abis]`) - #147017 (FCW for repr(C) enums whose discriminant values do not fit into a c_int or c_uint) - #148459 (bootstrap: Split out a separate `./x test bootstrap-py` step) - #148468 (add logging to `fudge_inference_if_ok`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #144529 - beetrees:pass-indirectly-attr, r=bjorn3 Add `#[rustc_pass_indirectly_in_non_rustic_abis]` This PR adds an internal `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute that can be applied to structs. Structs marked with this attribute will always be passed using `PassMode::Indirect { on_stack: false, .. }` when being passed by value to functions with non-Rustic calling conventions. This is needed by #141980; see that PR for further details. cc `@joshtriplett`

error on non-rustic ABIs using unsized parameters tracking issue: #48055 This came up in #144529 (comment). The idea is that the layout of an unsized type is unstable (following the rust layout rules), and hence stable ABIs should not use unsized types. On stable, unsized types (or generics with a `?Sized` bound) are not accepted as parameters, so the errors introduced by this PR can only be observed when the unstable `unsized_fn_params` feature is enabled. r? `@bjorn3` cc `@RalfJung`

Zalathar · 2025-11-05T13:30:25Z

Perf results show a few regressions in large-workspace:

error on non-rustic ABIs using unsized parameters tracking issue: #48055 This came up in #144529 (comment). The idea is that the layout of an unsized type is unstable (following the rust layout rules), and hence stable ABIs should not use unsized types. On stable, unsized types (or generics with a `?Sized` bound) are not accepted as parameters, so the errors introduced by this PR can only be observed when the unstable `unsized_fn_params` feature is enabled. r? `@bjorn3` cc `@RalfJung`

folkertdev

How should I evaluate that regression? There is one minor optimization in a comment below, but beyond that I think the cost is additional queries for the attribute flag, and that is impossible to work around I think (plus should be mostly cached).

View changes since this review

folkertdev · 2025-11-05T15:35:44Z

compiler/rustc_middle/src/ty/mod.rs


+        // See `TyAndLayout::pass_indirectly_in_non_rustic_abis` for details.
+        if find_attr!(
+            self.get_all_attrs(did),


This could be re-used from earlier

Zalathar · 2025-11-05T22:43:04Z

I thought the regression looked real, but the same benchmarks bounced back in #148507 (comment), so maybe it’s noise?

workingjubilee · 2025-11-06T18:14:23Z

@folkertdev please feel free to submit the PR and we can run perf to see if it matters.

…ttrs, r=JonathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here rust-lang#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? `@JonathanBrouwer` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)

…ttrs, r=JonathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here rust-lang#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? ``@JonathanBrouwer`` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)

…ttrs, r=JonathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here rust-lang#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? ```@JonathanBrouwer``` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)

…ttrs, r=JonathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here rust-lang#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? ````@JonathanBrouwer```` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)

Rollup merge of #148600 - folkertdev:pass-indirectly-reuse-attrs, r=JonathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here #144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? ````@JonathanBrouwer```` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)

…onathanBrouwer re-use `self.get_all_attrs` result for pass indirectly attribute Could be a fix for a potential performance regression reported here rust-lang/rust#144529 (comment). Apparently the regression later disappeared. Nevertheless, this seems like a decent refactor. r? ````@JonathanBrouwer```` (vaguely attribute-related, maybe there are other optimizations to that PR that we're missing)

…ngjubilee Rework `c_variadic` tracking issue: rust-lang#44930 related PR: rust-lang#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang#44930 r? `@joshtriplett`

Rework `c_variadic` tracking issue: #44930 related PR: #144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, #144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: #141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: #44930 r? `@joshtriplett`

…ngjubilee Rework `c_variadic` tracking issue: rust-lang#44930 related PR: rust-lang#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang#44930 r? `@joshtriplett`

…ngjubilee Rework `c_variadic` tracking issue: rust-lang#44930 related PR: rust-lang#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang#44930 r? ``@joshtriplett``

…ngjubilee Rework `c_variadic` tracking issue: rust-lang#44930 related PR: rust-lang#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang#44930 r? ```@joshtriplett```

rustbot assigned SparrowLii Jul 27, 2025

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 27, 2025

beetrees mentioned this pull request Jul 27, 2025

c_variadic: make VaList abi-compatible with C #141980

Open

RalfJung reviewed Jul 27, 2025

View reviewed changes

beetrees force-pushed the pass-indirectly-attr branch from c0357c1 to 61196cb Compare July 27, 2025 17:23

RalfJung reviewed Jul 29, 2025

View reviewed changes

compiler/rustc_target/src/callconv/riscv.rs Show resolved Hide resolved

compiler/rustc_target/src/callconv/x86_64.rs Show resolved Hide resolved

beetrees force-pushed the pass-indirectly-attr branch from 61196cb to ed746a3 Compare July 29, 2025 15:27

beetrees force-pushed the pass-indirectly-attr branch from ed746a3 to d91160a Compare August 1, 2025 01:43

This comment has been minimized.

Sign in to view

beetrees force-pushed the pass-indirectly-attr branch from d91160a to 0401bf3 Compare August 1, 2025 01:59

rustbot assigned joshtriplett and unassigned SparrowLii Aug 4, 2025

beetrees force-pushed the pass-indirectly-attr branch from 0401bf3 to b8bd968 Compare September 1, 2025 15:34

This comment has been minimized.

Sign in to view

rustbot assigned bjorn3 and unassigned joshtriplett Sep 3, 2025

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

beetrees force-pushed the pass-indirectly-attr branch from b8bd968 to 1953e54 Compare September 10, 2025 20:29

This comment has been minimized.

Sign in to view

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 4, 2025

Zalathar mentioned this pull request Nov 4, 2025

Rollup of 4 pull requests #148472

Merged

bors merged commit fa9ea6d into rust-lang:master Nov 4, 2025
11 of 12 checks passed

rustbot added this to the 1.93.0 milestone Nov 4, 2025

folkertdev reviewed Nov 5, 2025

View reviewed changes

folkertdev mentioned this pull request Nov 6, 2025

re-use self.get_all_attrs result for pass indirectly attribute #148600

Merged

dvdplm mentioned this pull request Nov 14, 2025

Update toolchain to latest nightly (Nov 13) Rust-GPU/rust-gpu#460

Draft

folkertdev mentioned this pull request Dec 4, 2025

Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust (c_variadic) #44930

Open

3 tasks

	fn fn_abi_sanity_check<'tcx>(
	cx: &LayoutCx<'tcx>,
	fn_abi: &FnAbi<'tcx, Ty<'tcx>>,
	spec_abi: ExternAbi,
	) {

Add #[rustc_pass_indirectly_in_non_rustic_abis] #144529

Add #[rustc_pass_indirectly_in_non_rustic_abis] #144529

Uh oh!

Conversation

beetrees commented Jul 27, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 27, 2025

Uh oh!

rustbot commented Jul 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jul 27, 2025

Uh oh!

RalfJung left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bors commented Jul 31, 2025

Uh oh!

rustbot commented Aug 1, 2025

Uh oh!

This comment has been minimized.

SparrowLii commented Aug 4, 2025

Uh oh!

rustbot commented Aug 4, 2025

Uh oh!

This comment has been minimized.

folkertdev commented Sep 3, 2025

Uh oh!

bors commented Sep 9, 2025

Uh oh!

This comment has been minimized.

bors commented Nov 4, 2025

Uh oh!

Zalathar commented Nov 4, 2025

Uh oh!

Uh oh!

Zalathar commented Nov 5, 2025

Uh oh!

folkertdev left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Zalathar commented Nov 5, 2025

Uh oh!

workingjubilee commented Nov 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

12 participants

Add `#[rustc_pass_indirectly_in_non_rustic_abis]` #144529

Add `#[rustc_pass_indirectly_in_non_rustic_abis]` #144529

beetrees commented Jul 27, 2025 •

edited by rustbot

Loading

folkertdev left a comment •

edited by rustbot

Loading