Tracking issue for feature(repr128); enums with 128-bit discriminants #56071
Comments
Centril
added
B-RFC-approved
Centril
removed
the
B-unstable
|
I actually double checked the RFC text and I didn't see mentions of |
|
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.
… 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.
… 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.
… 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.
|
Is there any progress on this? My use-case is that I often use 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? |
|
I believe there hasn't been any progress on this since the original comment. |
|
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. |
|
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). |
|
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
added
the
S-tracking-unimplemented
joshtriplett
added
the
A-LLVM
…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
…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
=== stdout === === stderr === warning: the feature `repr128` is incomplete and may not be safe to use and/or cause compiler crashes --> <anon>:3:12 | 3 | #![feature(repr128, arbitrary_enum_discriminant)] | ^^^^^^^ | = note: see issue #56071 <rust-lang/rust#56071> for more information = note: `#[warn(incomplete_features)]` on by default warning: the feature `arbitrary_enum_discriminant` has been stable since 1.66.0 and no longer requires an attribute to enable --> <anon>:3:21 | 3 | #![feature(repr128, arbitrary_enum_discriminant)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(stable_features)]` on by default warning: 2 warnings emitted ==============
|
There seems to be an issue with #[repr(i128)] I discovered this when working on https://reviews.llvm.org/D149213 Also something is wrong when those enums are defined as globals. Their values are completely off in both no_std and std compilations. I'm not 100% sure it's not LLDB issues or the change I did in LLDB but what I observed when debugging this is that this structure represents a variant __0 field having offset 16, but in reality in memory it was located at offset 8. So it's either the bug in debug info or in compiler. |
@VladimirMakaev Is this still an issue? I've checked the example from the diff locally on Rust nightly and everything seems to agree that |
… r=<try> Use the `enum2$` Natvis visualiser for repr128 C-style enums Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly. Tracking issue: rust-lang#56071 try-job: x86_64-msvc
… r=<try> Use the `enum2$` Natvis visualiser for repr128 C-style enums Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly. Tracking issue: rust-lang#56071 try-job: x86_64-msvc
… r=<try> Use the `enum2$` Natvis visualiser for repr128 C-style enums Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly. Tracking issue: rust-lang#56071 try-job: x86_64-msvc
… r=<try> Use the `enum2$` Natvis visualiser for repr128 C-style enums Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly. Tracking issue: rust-lang#56071 try-job: x86_64-msvc
This issue tracks
repr128, i.e. "enums with 128-bit discriminant" as per rust-lang/rfcs#1504.Originally this was tracked in #35118.
- @nagisa
The text was updated successfully, but these errors were encountered: