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

Centril · 2018-11-19T13:01:37Z

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

The text was updated successfully, but these errors were encountered:

clarfonthey · 2018-11-20T15:46:23Z

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 · 2018-11-20T16:13:21Z

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.

… r=jonas-schievink Mark `repr128` as `incomplete_features` As mentioned in rust-lang#56071 and noticed in rust-lang#77457, `repr(u128)` and `repr(i128)` do not work properly due to lack of LLVM support. We should thus warn users trying to use the feature that they may encounter ICEs when using it. Closes rust-lang#77457.

marmeladema · 2020-12-11T16:07:39Z

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 · 2020-12-14T13:30:09Z

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

dan-da · 2021-09-01T20:31:26Z

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 · 2021-09-01T21:37:01Z

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 · 2021-09-01T22:21:16Z

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.

…r=nagisa Pass 128-bit C-style enum enumerator values to LLVM Pass the full 128 bits of C-style enum enumerators through to LLVM. This means that debuginfo for C-style repr128 enums is now emitted correctly for DWARF platforms (as compared to not being correctly emitted on any platform). Tracking issue: rust-lang#56071

clarfonthey · 2024-12-24T18:41:13Z

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 · 2024-12-28T09:44:05Z

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:

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.
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 · 2025-02-04T22:43:05Z

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

beetrees · 2025-02-25T09:16:27Z

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

scottmcm · 2025-02-26T16:51:53Z

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 · 2025-02-26T17:25:27Z

@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.

…t, r=jieyouxu Add DWARF test case for non-C-like `repr128` enums LLVM 20 fixes DWARF debuginfo for non-C-like 128-bit enums: this PR adds a test case to the `repr128-dwarf` test to ensure that LLVM doesn't regress in the future. Tracking issue: rust-lang#56071

Rollup merge of rust-lang#137643 - beetrees:repr128-dwarf-variant-test, r=jieyouxu Add DWARF test case for non-C-like `repr128` enums LLVM 20 fixes DWARF debuginfo for non-C-like 128-bit enums: this PR adds a test case to the `repr128-dwarf` test to ensure that LLVM doesn't regress in the future. Tracking issue: rust-lang#56071

beetrees · 2025-03-09T20:12:08Z

Stabilisation report now available at #138285.

…li-obk Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions` This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge rust-lang#137306 then this can be reverted. Tracking issue: rust-lang#56071

Rollup merge of rust-lang#138282 - beetrees:repr128-not-ffi-safe, r=oli-obk Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions` This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge rust-lang#137306 then this can be reverted. Tracking issue: rust-lang#56071

…ross,bjorn3 Stabilize `repr128` ## Stabilisation report The `repr128` feature ([tracking issue](rust-lang#56071)) 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: ```rust #[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](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in rust-lang#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 rust-lang#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](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values. - [debuginfo/msvc-pretty-enums.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct. - [run-make/repr128-dwarf](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct. Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`. Closes rust-lang#56071 Closes rust-lang/reference#1368 r? lang `@rustbot` label +I-lang-nominated +T-lang

…ross,bjorn3 Stabilize `repr128` ## Stabilisation report The `repr128` feature ([tracking issue](rust-lang#56071)) 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: ```rust #[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](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in rust-lang#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 rust-lang#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](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values. - [debuginfo/msvc-pretty-enums.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct. - [run-make/repr128-dwarf](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct. Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`. Closes rust-lang#56071 Closes rust-lang/reference#1368 r? lang ``@rustbot`` label +I-lang-nominated +T-lang

…ross,bjorn3 Stabilize `repr128` ## Stabilisation report The `repr128` feature ([tracking issue](rust-lang#56071)) 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: ```rust #[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](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in rust-lang#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 rust-lang#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](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values. - [debuginfo/msvc-pretty-enums.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct. - [run-make/repr128-dwarf](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct. Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`. Closes rust-lang#56071 Closes rust-lang/reference#1368 r? lang ```@rustbot``` label +I-lang-nominated +T-lang

Centril mentioned this issue Nov 19, 2018

Tracking issue for 128-bit integer support (RFC 1504) #35118

Closed

5 tasks

Centril removed the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Nov 19, 2018

Aaron1011 mentioned this issue Jun 16, 2020

Add unstable core::mem::variant_count intrinsic #73418

Merged

This was referenced Oct 3, 2020

Panic in nightly using repr(u128) with constant higher than is representable #77457

Closed

Mark repr128 as incomplete_features #77488

Merged

illicitonion mentioned this issue Oct 31, 2021

Difference between num_enum and num_derive ? illicitonion/num_enum#61

Closed

scottmcm added the S-tracking-unimplemented Status: The feature has not been implemented. label Jun 1, 2022

joshtriplett added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jun 8, 2022

wesleywiser mentioned this issue Jul 7, 2022

debuginfo: Generalize C++-like encoding for enums. #98393

Merged

2 tasks

tamird mentioned this issue Jul 9, 2022

Tracking issue for integer_atomics #99069

Open

2 tasks

scottmcm mentioned this issue Aug 17, 2022

ICE: repr 128 + debuginfo #100612

Closed

beetrees mentioned this issue Oct 5, 2022

Pass 128-bit C-style enum enumerator values to LLVM #102717

Merged

rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Dec 28, 2024

beetrees mentioned this issue Feb 25, 2025

Mark feature(repr128) as a complete feature #137592

Closed

beetrees mentioned this issue Feb 25, 2025

Add DWARF test case for non-C-like repr128 enums #137643

Merged

rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 26, 2025

This was referenced Mar 9, 2025

Add #[repr(u128)]/#[repr(i128)] enums to improper_ctypes_definitions #138282

Merged

Stabilize repr128 #138285

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

Centril commented Nov 19, 2018

clarfonthey commented Nov 20, 2018

Uh oh!

nagisa commented Nov 20, 2018

Uh oh!

marmeladema commented Dec 11, 2020

Uh oh!

varkor commented Dec 14, 2020

Uh oh!

dan-da commented Sep 1, 2021

Uh oh!

clarfonthey commented Sep 1, 2021

Uh oh!

dan-da commented Sep 1, 2021

Uh oh!

clarfonthey commented Dec 24, 2024 •

edited

Loading

Uh oh!

beetrees commented Dec 28, 2024 •

edited

Loading

Uh oh!

beetrees commented Feb 4, 2025

Uh oh!

beetrees commented Feb 25, 2025

Uh oh!

scottmcm commented Feb 26, 2025

Uh oh!

traviscross commented Feb 26, 2025 •

edited

Loading

Uh oh!

beetrees commented Mar 9, 2025

Uh oh!

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

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

Comments

Centril commented Nov 19, 2018

clarfonthey commented Nov 20, 2018

Uh oh!

nagisa commented Nov 20, 2018

Uh oh!

marmeladema commented Dec 11, 2020

Uh oh!

varkor commented Dec 14, 2020

Uh oh!

dan-da commented Sep 1, 2021

Uh oh!

clarfonthey commented Sep 1, 2021

Uh oh!

dan-da commented Sep 1, 2021

Uh oh!

clarfonthey commented Dec 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beetrees commented Dec 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beetrees commented Feb 4, 2025

Uh oh!

beetrees commented Feb 25, 2025

Uh oh!

scottmcm commented Feb 26, 2025

Uh oh!

traviscross commented Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beetrees commented Mar 9, 2025

Uh oh!

clarfonthey commented Dec 24, 2024 •

edited

Loading

beetrees commented Dec 28, 2024 •

edited

Loading

traviscross commented Feb 26, 2025 •

edited

Loading