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,

) {

We totally can

if arg.layout.pass_indirectly_in_non_rustic_abis(cx) { assert_matches!(arg.mode, PassMode::Indirect { on_stack: false, .. }); }

How do we make sure that triggers for every ABI though? Can we add an unused definition to core that uses this attribute and a function using it, so that the code path is exercised? E.g. put this somewhere

#[rustc_pass_indirectly_in_non_rustic_abis] struct S(usize); #[expect(unused)] fn indirect_argument(_: S) {}

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

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.

rustbot · 2025-09-10T20:30:03Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

bors · 2025-09-13T08:20:39Z

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

joshtriplett · 2025-09-17T09:57:53Z

Broadly speaking, this seems like a reasonable way to tag types for use with this special calling convention.

I can't speak to the maintainability of this approach, but generally speaking, I'm not sure it's possible to handle va_args any easier than this, for any ABIs where it's a special case. I'd suggest, in general, that when you add this attribute to a type, there should be copious cross-references between the type, the ABI tests that confirm it's passed correctly, and the compiler sources implementing this attribute, so that people who are adding a new ABI know to carefully add tests and check the passing of va_args. (And, hopefully, not duplicate the weird mistakes of existing architectures.)

folkertdev · 2025-09-17T10:13:12Z

compiler/rustc_abi/src/layout/ty.rs

+    /// If this method returns `true`, then this type should always have a `PassMode` of
+    /// `Indirect { on_stack: false, .. }` when being used as the argument type of a function with a
+    /// non-Rustic ABI (this is true for structs annotated with the
+    /// `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute).
+    ///
+    /// This function handles transparent types automatically.
+    pub fn pass_indirectly_in_non_rustic_abis<C>(mut self, cx: &C) -> bool


Some reference to array-to-pointer decay might be useful here to motivate why this function exists?

folkertdev · 2025-09-17T11:23:58Z

compiler/rustc_abi/src/layout/ty.rs

+        while self.is_transparent()
+            && let Some((_, field)) = self.non_1zst_field(cx)
+        {
+            self = field;
+        }
+        Ty::is_pass_indirectly_in_non_rustic_abis_flag_set(self)


so right now the type is only passed indirectly if the base type is passed indirectly. This just confused me for a while, I think this should also work:

#[repr(C)] struct Vanilla(i32); #[repr(transparent)] #[rustc_pass_indirectly_in_non_rustic_abis] struct Indirectly(Vanilla);

I.e. if any of the transparent wrappers is rustc_pass_indirectly_in_non_rustic_abis then the whole type should be passed indirectly.

RalfJung · 2025-09-17T11:59:13Z

Broadly speaking, this seems like a reasonable way to tag types for use with this special calling convention.

I can't speak to the maintainability of this approach, but generally speaking, I'm not sure it's possible to handle va_args any easier than this, for any ABIs where it's a special case. I'd suggest, in general, that when you add this attribute to a type, there should be copious cross-references between the type, the ABI tests that confirm it's passed correctly, and the compiler sources implementing this attribute, so that people who are adding a new ABI know to carefully add tests and check the passing of va_args. (And, hopefully, not duplicate the weird mistakes of existing architectures.)

Correct use of the attribute depends not just on the type but also its surrounding conventions -- for instance, it is already UB in C to even look at a va_args after it has been passed to another function, if I understood correctly. That's crucial because a Rust "pass_indirectly" type still passes a copy of the argument value to the callee, whereas in C it passes effectively an implicit reference -- if the callee mutates the argument, a C caller will see the mutations, a Rust caller will not.

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

Rework c_variadic #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

Add #[rustc_pass_indirectly_in_non_rustic_abis]

1953e54

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

folkertdev reviewed Sep 17, 2025

View reviewed changes

	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

Are you sure you want to change the base?

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!

rustbot commented Sep 10, 2025

Uh oh!

bors commented Sep 13, 2025

Uh oh!

joshtriplett commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

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

RalfJung commented Sep 17, 2025 •

edited

Loading