Skip to content

Distinguish repr(C) ZSTs from others in ABI compatibility rules #157973

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Jules-Bertholet wants to merge 6 commits into
base: main
Choose a base branch
from
+13 −3
Open

Distinguish repr(C) ZSTs from others in ABI compatibility rules #157973

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
31d03e7
Distinguish `repr(C)` ZSTs from others in ABI compatibility rules
Jules-Bertholet Jun 16, 2026
34de188
Make most arrays non-trivial
Jules-Bertholet Jun 19, 2026
41e5d13
Improve wording
Jules-Bertholet Jul 2, 2026
a01211b
Future-proofing
Jules-Bertholet Jul 2, 2026
a9bed71
Improve wording
Jules-Bertholet Jul 3, 2026
3e86bb0
Avoid negation
Jules-Bertholet Jul 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 13 additions & 3 deletions library/core/src/primitive_docs.rs
View file
Open in desktop

@Mark-Simulacrum Mark-Simulacrum Jun 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Some C ABIs pass and return ZSTs by pointer. But () should never be returned by pointer, as it must match void. To account for this, we have to weaken the present guarantee of "any two types with size 0 and alignment 1 are ABI-compatible" to exclude repr(C).

I think the implication here is that () is repr(C)? Am I reading that right? Where do we make that guarantee? Or is the thinking that the language here would make () and #[repr(C)] struct Foo; not ABI compatible?

One callout is that ZSTs aren't (I think?) standardized -- C and C++ without extensions both require types to be non-ZST if I remember right (e.g., see https://stackoverflow.com/a/2632075). Maybe that has changed since then though?

It seems like at minimum, it would be nice to avoid weakening this guarantee for Rust ABI even if we do so for C ABIs as a result of the weird platforms.

@Jules-Bertholet Jules-Bertholet Jun 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Or is the thinking that the language here would make () and #[repr(C)] struct Foo; not ABI compatible?

Yes, this.

One callout is that ZSTs aren't (I think?) standardized

Correct.

Original file line number Diff line number Diff line change
Expand Up @@ -1841,9 +1841,19 @@ mod prim_ref {}
/// call will be valid ABI-wise. The callee receives the result of transmuting the function pointer
/// from `fn()` to `fn(i32)`; that transmutation is itself a well-defined operation, it's just
/// almost certainly UB to later call that function pointer.)
/// - Any two types with size 0 and alignment 1 are ABI-compatible.
/// - A `repr(transparent)` type `T` is ABI-compatible with its unique non-trivial field, i.e., the
/// unique field that doesn't have size 0 and alignment 1 (if there is such a field).
/// - Any two types fulfilling all the following conditions are ABI-compatible;
/// such types are said to have "trivial ABI":
Comment on lines +1844 to +1845

@RalfJung RalfJung Jul 2, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
/// - Any two types fulfilling all the following conditions are ABI-compatible;
/// such types are said to have "trivial ABI":
/// - Any two types with "trivial ABI" are ABI-compatible.
/// A type has trivial ABI if is satisfies all of the following:

View changes since the review

/// - It has size 0.
/// - It has alignment 1.
/// - One of the following apply:
/// - It is a `repr(Rust)` (implicitly or explicitly, possibly with additional flags such as `packed`) `struct`, `enum`, `union` (regardless of its fields).
/// - It is a [tuple][prim_tuple] (regardless of its fields, and including [`()`][prim_unit]).
/// - It is a `repr(transparent)` `struct`, `enum`, or `union`, and all fields have trivial ABI.
/// - It is an array, and its element type has trivial ABI. (This requirement applies even to arrays of length 0.)
/// - It is [the never type `!`][prim_never].
/// - It is a function item type or closure type.
/// - A `repr(transparent)` type is ABI-compatible with its unique field that does not have trivial ABI
/// (as defined above), if such a field exists.
/// - `i32` is ABI-compatible with `NonZero<i32>`, and similar for all other integer types.
/// - If `T` is guaranteed to be subject to the [null pointer
/// optimization](option/index.html#representation), and `E` is an enum satisfying the following
Expand Down
Loading