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)]
enum Foo {
    One = 1,
    Two,
    Big = u128::MAX,
}

#[repr(i128)]
enum Bar {
    HasThing(u16) = 42,
    HasSomethingElse(i64) = u64::MAX as i128 + 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
Closes rust-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.

[scottmcm]

I don't think we need to couple the C ABI conversion to stabilizing it for Rust, at least. I could imagine that because of C annoyances that it might be worth linting against for extern "C" even if it's completely fine to use in all-Rust code.

And if we're emitting the right thing, I don't think we need to wait on debuggers either. Users can make their own decisions about whether that's something that they would choose not to use it for. And from a "what's in the lang spec" perspective, debug info is always a QoI thing anyway, not something that even must work.

@rfcbot reviewed

[tmandry]

I'm convinced by @scottmcm that we don't need to block on C ABI or debugger support for this.

@rfcbot reviewed

[traviscross]

Good enough.

@rfcbot resolve decide-on-137306

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[beetrees]

@traviscross is there anything blocking this now the FCP is complete?

[traviscross]

Thanks for the ping. Looks OK to me. @RalfJung, if you would, have a look and ensure this all looks in order to you also, then r=me along with your review.

r? @RalfJung

[RalfJung]

I'm not sure what I'd have to add here -- I am not an expert for the all the little "fun" details of what happens with 128bit integers on various targets and C compilers. So, sorry, I can't help here. Maybe @workingjubilee or @bjorn3 can?

r? @bjorn3

[bjorn3]

Shouldn't this have been marked as non-incomplete feature first when it got fully fixed?

[bjorn3]

In any case, based on reading the tracking issue, I do believe all blockers are resolved.

@bors r=traviscross,bjorn3

[bors]

📌 Commit 30f13ca has been approved by traviscross,bjorn3

It is now in the queue for this repository.