`repr(transparent)`: don't consider most length-0 arrays trivial by Jules-Bertholet · Pull Request #155984 · rust-lang/rust

Jules-Bertholet · 2026-04-30T03:43:38Z

With this PR, an array type is considered trivial for the purpose of repr(transparent) only if its element type is—we emit the repr_transparent_non_zst_fields FCW (#78586) otherwise. To support a pattern used by the ghost crate, we also permit all array types with length 0 when they are contained within a repr(Rust, packed(1)) ADT.

This has two benefits:

Forbid non-portable definitions

Some types have alignment 1 only on certain platforms. Prior to this PR, the following snippet would compile on AVR, and only on AVR:

#[repr(transparent)]
struct Foo(i32, [u16; 0]);

After this PR, the above now fails to compile on any target.

FFI and CFI compatibility

We want to add support for Control Flow Integrity to Rust at some point. There are some good reasons to want CFI to consider *const [u8; 0] and *const [u8; 1] compatible with one another. But that means we must consider *const [u8; 0] and *const () to be CFI-incompatible. Declaring [u8; 0] non-trivial for repr(transparent) makes that easier to achieve. See discussion on Zulip:
https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/ABI-compatibility.20rules.20of.20ZST.20types/near/591412488

@rustbot label T-lang needs-fcp A-repr
Also needs a crater run.

rustbot · 2026-04-30T03:43:43Z

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 20 candidates

RalfJung · 2026-04-30T10:36:54Z

+                if elem_trivial {
+                    check_unsuited(tcx, typing_env, *elem_ty)


Why do you allow any arrays here? Seems easier to just reject them all?
I'd be surprised if there is much/any use of arrays as "trivial" types in repr(transparent).

View changes since the review

I think it's conceptually nice to treat "array with element type T" the same as "struct with field of type T". And it turns out that we need some non-trivial complexity anyway, to support the ghost crate.

to support the ghost crate.

That seems like a different problem. I'm not even sure we should.

To clarify: this PR doesn't fix using types from ghost in repr(transparent). As of https://github.com/dtolnay/ghost/releases/tag/0.1.21, ghost is already fixed. The packed check is so that we don't break it again in a different and harder-to-fix way.

Ah, do they also use arrays? That is kind of annoying...

FWIW based on the previous crater run I think there are no uses of ghost on crates.io that require it to be "trivial" for repr(transparent).

That said, I think I could live with a more principled solution to this: stop checking anything ABI-related (repr(C), array) once we are inside a repr(Rust) type. Your PR is checking for "repr(Rust) packed(1)" and only suppresses the error check, which seems to be overfitting to ghost specifically.

We still won't learn how relevant it actually is. So that run is IMO an entire waste of resources. OTOH if we reject all arrays we'll see how often the pattern occurs and then we can still adjust the check later.

I don't think crater will necessarily catch all cases of this breakage. ghost has nearly 17 million lifetime downloads on crates.io, but its most popular dependent has ~60k. That suggests there is a lot of usage outside crates.io.

More broadly, I just don't think this sort of breakage is acceptable given Rust's stability policies. Breaking changes that are fundamentally difficult or even impossible for crates to work around should require more justification than "it's slightly easier".

Worth asking: @dtolnay what do you think about this?

We are not discussing which change should actually land. We are discussing which change to run with crater. I am arguing that we get better data by cratering this PR in a version that rejects all arrays.

Either I am right and crater finds no array uses. That's good to know. I would argue that's good enough to make this an FCW; if there's tons of private use of this that relies on arrays in repr(transparent) we'll hear about it during the warning period. Ultimately its up to the lang team to weigh this though, our task is to give them the data they need for a decision.

Or crater finds some (many?) array uses, giving us clear evidence that yes we do need more targeted checks.

You have so far not at all engaged with that argument.

I have queued up a crater run in #156114 so that we can get that data.

RalfJung · 2026-04-30T10:38:29Z

Also needs a crater run.

For that we need a version of this that emits a hard error.

With this PR, an array type is considered trivial for the purpose of `repr(transparent)` only if its element type is—we emit the `repr_transparent_non_zst_fields` FCW otherwise. This has two benefits: ## Forbid non-portable definitions Some types have alignment 1 only on certain platforms. Prior to this PR, the following snippet would compile on AVR, and *only* on AVR: ```rust #[repr(transparent)] struct Foo(i32, [u16; 0]); ``` After this PR, the above now fails to compile on any target. ## FFI and CFI compatibility We want to add support for Control Flow Integrity to Rust at some point. There are some good reasons to want CFI to consider `*const [u8; 0]` and `*const [u8; 1]` compatible with one another. But that means we must consider `*const [u8; 0]` and `*const ()` to be CFI-incompatible. Declaring `[u8; 0]` non-trivial for `repr(transparent)` makes that easier to achieve. See discussion on Zulip: <https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/ABI-compatibility.20rules.20of.20ZST.20types/near/591412488>

Needed to support the `ghost` crate.

rustbot · 2026-05-01T00:45:07Z

The Miri subtree was changed

cc @rust-lang/miri

Jules-Bertholet · 2026-05-01T02:57:16Z

The PR should now be ready for crater

@rustbot ready

RalfJung · 2026-05-01T08:03:30Z

I don't think this is the check we even want, that's too many ad-hoc hacks. Let's just check the version where all arrays get rejected, to get a baseline that will tell us whether there's any evidence in the ecosystem that these hacks are needed.

RalfJung · 2026-05-01T21:47:38Z

+                        typing_env,
+                        t,
+                        inside_repr_rust_packed_1
+                            || def.repr().pack.is_some_and(|a| a.bytes() == 1),


This will also be true for repr(Swift, packed) if we get that in the future... I guess there's no good way to check for repr(Rust, packed)?

View changes since the review

There isn't, sadly

One verbose way to achieve this would be an exhaustive field match on ReprOptions similar to #155418.

RalfJung · 2026-05-01T21:49:17Z

@bors try

rust-bors · 2026-05-01T21:49:22Z

⌛ Trying commit fe0c86e with merge 47f5a12…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/25234662750

`repr(transparent)`: don't consider most length-0 arrays trivial

RalfJung · 2026-05-01T21:57:11Z

+                    return ControlFlow::Continue(());
+                }
+
+                let elem_layout = tcx.layout_of(typing_env.as_query_input(*elem_ty));


Suggested change

let elem_layout = tcx.layout_of(typing_env.as_query_input(*elem_ty));

// We are concerned about arrays for two reasons:

// - Arrays are part of the C ABI so we don't want to make assumptions about their ABI

// - The alignment of zero-sized arrays is target-dependent.

// So we only accept arrays whose element types are themselves 1-ZST that are "trivial" for repr(transparent).

// This unnecessarily considers a repr(Rust) newtype around a `[u8; 1]` to be "unsuited", but that's not a big loss (and it can be worked around by adding `packed`).

let elem_layout = tcx.layout_of(typing_env.as_query_input(*elem_ty));

View changes since the review

RalfJung · 2026-05-01T21:58:14Z

Please add tests at least for

newtype around [u16; 0]

newtype around [u8; 0] (with a comment explaining that rejecting this is unnecessary but it's not worth the extra logic to accept it)

the type generated by ghost

View changes since the review

RalfJung · 2026-05-01T21:58:35Z

            #[rustc_abi(assert_eq)]
            type TestC = (extern "C" fn($t1) -> $t1, extern "C" fn($t2) -> $t2);
+            #[rustc_abi(assert_eq)]
+            type TestSystem = (extern "system" fn($t1) -> $t1, extern "system" fn($t2) -> $t2);


This has nothing to do with repr(transparent), does it?

View changes since the review

With the whole business of the Windows ABI passing some empty structs by pointer, I figured that an extra check in this area can't hurt. I don't think this PR would break anything there, but that's what tests are for

Maybe make this a separate PR then so we don't mix up the discussion.

We run this test on lots of targets, and for almost all of them "system" is the same as "C". So I think this is mostly a waste of time. However you make a good point -- it would make sense to also test some of the target-specific ABIs here. We can just add those under cfg(...) then I think?

RalfJung · 2026-05-01T21:59:35Z

    for field in field_infos {
        if field.trivial
-            && let Some(unsuited) = check_unsuited(tcx, typing_env, field.ty).break_value()
+            && let Some(unsuited) = check_unsuited(tcx, typing_env, field.ty, false).break_value()


Suggested change

&& let Some(unsuited) = check_unsuited(tcx, typing_env, field.ty, false).break_value()

&& let Some(unsuited) = check_unsuited(tcx, typing_env, field.ty, /* inside_repr_rust_packed_1 */ false).break_value()

View changes since the review

RalfJung · 2026-05-01T22:00:49Z

+                        inside_repr_rust_packed_1
+                            || def.repr().pack.is_some_and(|a| a.bytes() == 1),


This ... || ... expression seems worth let-binding before the map.

View changes since the review

RalfJung · 2026-05-01T22:02:17Z

+            ty::Array(elem_ty, len) => {
+                // If we are inside a `#[repr(Rust, packed(1))]` ADT,
+                // the alignment is guaranteed to be 1 and Rust has full control over the ABI.
+                // Therefore, we can allow any length-0 array.


Why only 0-length arrays?

View changes since the review

#[repr(Rust, packed(1))] guarantees alignment 1, but not size 0. If the element type contains e.g. repr(C), it might not be portably 0-sized. The if elem_trivial { check_unsuited(...) } check below allows the non-0-length arrays that we can safely allow.

I suppose we could allow types like #[repr(Rust, packed(1))] struct Foo([[u128; 0]; 42]), which this PR currently rejects. But again, that would conflict with your preference for less complexity.

We only ever call check_trivial on types that we already know to be zero-sized. So I think you can remove the length check and everything will remain correct. Or am I missing something?

We only ever call check_trivial on types that we already know to be zero-sized

… on the current target. The element type could be an empty repr(C) struct. We have to reject this:

#[repr(C)] struct MaybeZst; #[repr(packed)] struct MaybeZstWrap([MaybeZst; 42]); #[repr(transparent)] struct ThisShouldntCompile(u32, MaybeZstWrap);

I see. That warrants a comment in the code and a test case.

RalfJung · 2026-05-01T22:13:55Z

@bors try cancel
Since running crater on this would be a waste of resources. Crater is not cheap, we should make sure we get good information out of such a run.

rust-bors · 2026-05-01T22:13:58Z

Try build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/25234662750

rustbot assigned dingxiangfei2009 Apr 30, 2026

rustbot added 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 Apr 30, 2026

rustbot added A-repr Area: the `#[repr(stuff)]` attribute needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. T-lang Relevant to the language team labels Apr 30, 2026

This comment has been minimized.

Sign in to view

RalfJung reviewed Apr 30, 2026

View reviewed changes

Jules-Bertholet force-pushed the nontrivial-array branch 2 times, most recently from 72a9d17 to d4c13b1 Compare April 30, 2026 23:11

This comment has been minimized.

Sign in to view

Jules-Bertholet added 2 commits April 30, 2026 20:44

Allow length-0 arrays inside #[repr(Rust, packed(1))]

2af89b0

Needed to support the `ghost` crate.

Jules-Bertholet force-pushed the nontrivial-array branch from c5c22f8 to 2af89b0 Compare May 1, 2026 00:45

[DO NOT MERGE] Make it a hard error for crater

fe0c86e

Jules-Bertholet marked this pull request as draft May 1, 2026 02:56

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 1, 2026

RalfJung reviewed May 1, 2026

View reviewed changes

rust-bors Bot pushed a commit that referenced this pull request May 1, 2026

Auto merge of #155984 - Jules-Bertholet:nontrivial-array, r=<try>

47f5a12

`repr(transparent)`: don't consider most length-0 arrays trivial

RalfJung reviewed May 1, 2026

View reviewed changes

RalfJung mentioned this pull request May 3, 2026

repr(transparent): never consider arrays trivial for the ABI #156114

Draft

-                let elem_layout = tcx.layout_of(typing_env.as_query_input(*elem_ty));
+                // We are concerned about arrays for two reasons:
+                // - Arrays are part of the C ABI so we don't want to make assumptions about their ABI
+                // - The alignment of zero-sized arrays is target-dependent.
+                // So we only accept arrays whose element types are themselves 1-ZST that are "trivial" for repr(transparent).
+                // This unnecessarily considers a repr(Rust) newtype around a `[u8; 1]` to be "unsuited", but that's not a big loss (and it can be worked around by adding `packed`).
+                let elem_layout = tcx.layout_of(typing_env.as_query_input(*elem_ty));

	&& let Some(unsuited) = check_unsuited(tcx, typing_env, field.ty, false).break_value()
	&& let Some(unsuited) = check_unsuited(tcx, typing_env, field.ty, /* inside_repr_rust_packed_1 */ false).break_value()

		inside_repr_rust_packed_1
		\|\| def.repr().pack.is_some_and(\|a\| a.bytes() == 1),

Uh oh!

Conversation

Jules-Bertholet commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Forbid non-portable definitions

FFI and CFI compatibility

Uh oh!

rustbot commented Apr 30, 2026

Uh oh!

This comment has been minimized.

RalfJung Apr 30, 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!

Choose a reason for hiding this comment

Uh oh!

Jules-Bertholet May 1, 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!

RalfJung May 1, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 2, 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 Apr 30, 2026

Uh oh!

This comment has been minimized.

rustbot commented May 1, 2026

Uh oh!

Jules-Bertholet commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented May 1, 2026

Uh oh!

RalfJung May 1, 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!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented May 1, 2026

Uh oh!

rust-bors Bot commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung May 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 1, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 1, 2026 • 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

Jules-Bertholet commented Apr 30, 2026 •

edited

Loading

RalfJung Apr 30, 2026 •

edited

Loading

Jules-Bertholet May 1, 2026 •

edited

Loading

RalfJung May 1, 2026 •

edited

Loading

RalfJung May 2, 2026 •

edited

Loading

Jules-Bertholet commented May 1, 2026 •

edited

Loading

RalfJung May 1, 2026 •

edited

Loading

rust-bors Bot commented May 1, 2026 •

edited

Loading

RalfJung May 1, 2026 •

edited by rustbot

Loading

RalfJung May 1, 2026 •

edited by rustbot

Loading

RalfJung May 1, 2026 •

edited by rustbot

Loading

RalfJung May 1, 2026 •

edited by rustbot

Loading

RalfJung May 1, 2026 •

edited by rustbot

Loading

RalfJung May 1, 2026 •

edited by rustbot

Loading

RalfJung May 2, 2026 •

edited

Loading

Jules-Bertholet May 2, 2026 •

edited

Loading