Skip to content

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

New issue

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

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

Already on GitHub? # to your account

Open
Centril opened this issue Nov 19, 2018 · 20 comments · May be fixed by #138285
Open

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

Centril opened this issue Nov 19, 2018 · 20 comments · May be fixed by #138285
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC S-tracking-unimplemented Status: The feature has not been implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Nov 19, 2018

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

@Centril Centril added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Nov 19, 2018
@Centril Centril removed the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Nov 19, 2018
@clarfonthey
Copy link
Contributor

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
Copy link
Member

nagisa commented Nov 20, 2018

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.

JohnTitor added a commit to JohnTitor/rust that referenced this issue Oct 12, 2020
… 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.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Oct 12, 2020
… 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.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Oct 22, 2020
… 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.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Oct 23, 2020
… 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
Copy link
Contributor

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
Copy link
Member

varkor commented Dec 14, 2020

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

@dan-da
Copy link

dan-da commented Sep 1, 2021

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
Copy link
Contributor

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
Copy link

dan-da commented Sep 1, 2021

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.

@scottmcm scottmcm added the S-tracking-unimplemented Status: The feature has not been implemented. label Jun 1, 2022
@joshtriplett joshtriplett added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jun 8, 2022
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 21, 2022
…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
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
…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
Copy link
Contributor

clarfonthey commented Dec 24, 2024

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
Copy link
Contributor

beetrees commented Dec 28, 2024

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?

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

beetrees commented Feb 4, 2025

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

@beetrees
Copy link
Contributor

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

@scottmcm
Copy link
Member

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
Copy link
Contributor

traviscross commented Feb 26, 2025

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

@rustbot rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 26, 2025
jhpratt added a commit to jhpratt/rust that referenced this issue Mar 4, 2025
…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
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Mar 4, 2025
…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
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Mar 5, 2025
…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
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Mar 5, 2025
…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
jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 5, 2025
…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
jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 5, 2025
…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
jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 5, 2025
…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
compiler-errors added a commit to compiler-errors/rust that referenced this issue Mar 6, 2025
…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
Noratrieb added a commit to Noratrieb/rust that referenced this issue Mar 6, 2025
…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
compiler-errors added a commit to compiler-errors/rust that referenced this issue Mar 6, 2025
…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
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 7, 2025
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
Copy link
Contributor

beetrees commented Mar 9, 2025

Stabilisation report now available at #138285.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 24, 2025
…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
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 24, 2025
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
jieyouxu added a commit to jieyouxu/rust that referenced this issue May 28, 2025
…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
tgross35 added a commit to tgross35/rust that referenced this issue May 28, 2025
…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
tgross35 added a commit to tgross35/rust that referenced this issue May 28, 2025
…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
jhpratt added a commit to jhpratt/rust that referenced this issue May 29, 2025
…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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC S-tracking-unimplemented Status: The feature has not been implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.