Stabilize repr128

[beetrees]

Stabilisation report

The repr128 feature (tracking issue) allows the use of #[repr(u128)] and #[repr(i128)] on enums in the same way that other primitive representations such as #[repr(u64)] can be used. For example:

#[repr(u128)]enumFoo{One = 1,Two,Big = u128::MAX,}#[repr(i128)]enumBar{HasThing(u16) = 42,HasSomethingElse(i64) = u64::MAXasi128 + 1,HasNothing,}

This is the final part of adding 128-bit integers to Rust (RFC 1504); all other parts of 128-bit integer support were stabilised in #49101 back in 2018.

From a design perspective, #[repr(u128)]/#[repr(i128)] function like #[repr(u64)]/#[repr(i64)] but for 128-bit integers instead of 64-bit integers. The only differences are:

• FFI safety: as u128/i128 are not currently considered FFI safe, neither are #[repr(u128)]/#[repr(i128)] enums (I discovered this wasn't the case while drafting this stabilisation report, so I have submitted Add #[repr(u128)]/#[repr(i128)] enums to improper_ctypes_definitions #138282 to fix this).
• Debug info: while none of the major debuggers currently support 128-bit integers, as of LLVM 20 rustc will emit valid debuginfo for both DWARF and PDB (PDB makes use of the same natvis that is also used for all enums with fields, whereas DWARF has native support).

Tests for #[repr(u128)]/#[repr(i128)] enums include:

• ui/enum-discriminant/repr128.rs: checks that 128-bit enum discriminants have the correct values.
• debuginfo/msvc-pretty-enums.rs: checks the PDB debuginfo is correct.
• run-make/repr128-dwarf: checks the DWARF debuginfo is correct.

Stabilising this feature does not require any changes to the Rust Reference as the documentation on primitive representations already includes u128 and i128.

Closes#56071
Closesrust-lang/reference#1368

r? lang

@rustbot label +I-lang-nominated +T-lang

[rustbot]

Some changes occurred in tests/rustdoc-json

cc @aDotInTheVoid

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

This PR modifies run-make tests.

cc @jieyouxu

[traviscross]

@rfcbot fcp merge

Clearly, I think, we want this if we're sure it's ready (if nothing else from the perspective of consistency and minimizing caveats in our language specification). Let's start FCP, ping people, and file a concern to order this with respect to #137306.

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• decide-on-137306 resolved by Stabilize repr128 #138285 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

cc @rust-lang/opsem @rust-lang/wg-llvm @wesleywiser@workingjubilee@chorman0773@RalfJung@bjorn3@ehuss

[beetrees]

Fixed with a rebase.

@rustbot ready

[bjorn3]

@bors r=traviscross,bjorn3

[bors]

📌 Commit 467eeab has been approved by traviscross,bjorn3

It is now in the queue for this repository.