Tracking issue for feature(repr128); enums with 128-bit discriminants

[Centril]

This issue tracks repr128, i.e. "enums with 128-bit discriminant" as per rust-lang/rfcs#1504.
Originally this was tracked in #35118.

---

Nothing has changed re repr128… It is still the case that at least LLVM’s debuginfo API blocks us from implementing it at all. There’s very little incentive to work on it, though, and I’m not planning to do anything in that direction until a very convincing use-case for 128-bit enum discriminants comes up.

- @nagisa

[clarfonthey]

I actually double checked the RFC text and I didn't see mentions of repr(u128) anywhere. Is it still a feature that's desired?

[nagisa]

It’s a generic feature tied to integers in the language. It is not mentioned in the RFC because it would’ve implemented along with the integers themselves lest the roadblocks didn’t show up.

[marmeladema]

Is there any progress on this?

My use-case is that I often use #[repr(uXXX)] on enums with the enumflags2 crate in order to be able to manage set of values packed in an integer. That is very handy to avoid using a BTreeSet (heap allocation etc) but as soon as you have more then 64 different values (and less than 128 obviously), you would want to use #[repr(u128)] in stable but that's not currently possible.

I don't know if that's enough of a convincing use-case but that would be really handy to have this working in stable.

Is there any path forward that I could help with? Is LLVM debuginfo API still a blocker?

[varkor]

I believe there hasn't been any progress on this since the original comment.

[dan-da]

I have a use-case also, using an enum to represent fixed amount denominations for a cryptocurrency in development. u128 is necessary/desirable to have enough divisibility.

presently I am working around by defining the variants as a list (without integer values) and then using giant match statements to convert to/from. works, but is ugly.

[clarfonthey]

I mean, u64 allows up to 10^19, so I'm not sure what kinds of quantities you need to include. If we translate that into metric prefixes, that'd be all the way to exa (10^18).

[dan-da]

yes, well in fact we may use u64 in the end, but there has been discussion/debate around using u128 for greater divisibility, so our prototype code can build either way via a type alias. Unfortunately trying to use repr(u128) fails to compile, hence the workaround.

There are other ways we could represent this. We don't have to use an enum at all. It is simply the data structure that seems most suited to the task, so I was (a bit) surprised to find that u128 doesn't work the same as other integer types. Symmetry is beautiful, and this lacks symmetry.

[clarfonthey]

As I find myself wanting to use this, I'm curious what the specific limitations of the current implementation are. Since the feature exists in the compiler, it would be nice to properly document what exactly doesn't work and what's blocked on LLVM's side, so that folks know what the main blockers to this feature are.

[beetrees]

AFAIK, the only issue remaining is that, in DWARF debuginfo for enums with fields (aka not C-style), LLVM truncates the discriminants to 64-bit integers (or triggers an LLVM assertion if they are enabled and the discriminant doesn't fit in a 64-bit integer). I couldn't find an upstream LLVM issue tracking this, so I've opened one at llvm/llvm-project#119655. Apart from that debuginfo issue I think this is ready to be stabilised.

[bjoernager]

Would it be possible to temporarily disable debug info for DWARF in this case, stabilise the feature, and then re-enable debug info at a later time if/when the LLVM issue has been resolved? If I understand correctly that this is entirely due to debug info.

[beetrees]

It would definitely be possible to just omit discriminant values on the rustc side if they don't fit in 64 bits until the LLVM bug is fixed - even if rustc emitted the 128-bit discriminant value correctly, neither gdb nor lldb currently support enums with 128-bit discriminants. gdb doesn't support 128-bit discriminants at all (this can already be encountered on stable with types like Option<NonZero<u128>>), whereas lldb only supports discriminant values that fit in 32 bits (which can be encountered on stable using #[repr(u64)]).

AFAIK, it's up to the lang team whether it would be acceptable to stabilise the feature without full debuginfo emission support or not.

[clarfonthey]

If you can already encounter this bug on stable with Option<NonZero<u128>> I would say that's a pretty good argument in favour of stabilising this as-is, then determining a proper fix after the fact. But we'll have to see what the lang team thinks. Perhaps this should be nominated for that discussion?

[beetrees]

Since this nomination was made, the debuginfo issue with DWARF debuginfo generation for non-C-like repr(i128)/repr(u128) enums has now been fixed in LLVM 20, which rustc now uses. So the original question now only applies to the older versions of LLVM that rustc still supports (currently LLVM 18 and 19). I believe the options are:

1. Don't apply any workarounds for older LLVM versions. If rustc, using stock LLVM 18/19, compiles a non-C-like enum with a discriminant that doesn't fit in 64 bits, LLVM will truncate the discriminant in the DWARF debuginfo if LLVM assertions are disabled, or an LLVM assertion will occur if LLVM assertions are enabled. As the issue only affects DWARF debuginfo, the assertion will only occur when debuginfo is enabled.
2. Apply the workaround described in the original nomination statement on LLVM 18/19 only to avoid the potential LLVM assertion on those older LLVM versions.

Original nomination statement below:

---

@rustbot label +I-lang-nominated

feature(repr128) allows the use of #[repr(u128)] and #[repr(i128)] on enums, and is the only part of 128-bit integers support that hasn't been stabilised.

The only known issue is with DWARF debuginfo generation for non-C-like enums, as the LLVM DWARF debuginfo backend currently truncates variant discriminant values to 64 bits (LLVM issue llvm/llvm-project#119655, this causes an LLVM assertion if LLVM assertions are enabled and the value doesn't fit in 64 bits). As a tempoarary workaround, rustc could just not emit the discriminant value in the debuginfo if the discriminant doesn't fit in 64 bits: this wouldn't provide any worse user experience as neither gdb or lldb support 128-bit enum discriminants at the moment anyway (this can be encountered when debugging stable types like Option<NonZero<u128>>). The question for the lang team is: would it be acceptable to stabilise repr128 with the suggested tempoarary workaround, or is fixing llvm/llvm-project#119655 a prerequisite for stabilisation?

[beetrees]

The final LLVM debuginfo issue has been fixed by llvm/llvm-project#125578 🎉. I've requested a backport to LLVM 20.

[beetrees]

(I've updated the lang nomination statement to account for the debuginfo issue being fixed in LLVM 20.)

[scottmcm]

So long as the observable behaviour of this works as expected, let's stabilize it. I don't think we need to block on things like perfect debuginfo or perfect code coverage or whatever, so long as compiler folks are fine with treating it as a QoI issue.

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in lang triage today, and we agreed we'd like to see a stabilization PR here with a stabilization report. Please nominate that for us, and we'll FCP that. As @scottmcm said, our feeling was that we'll be inclined to go forward.

[beetrees]

Stabilisation report now available at #138285.