Stabilize `repr128` #138285

beetrees · 2025-03-09T20:09:47Z

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 · 2025-03-09T20:09:55Z

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

…3, r=compiler-errors triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search (… Followup to rust-lang#137958. I managed to miss a place, as shown by the questionable labeling of rust-lang#138285.

traviscross · 2025-03-10T07:47:41Z

@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 · 2025-03-10T07:47:43Z

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

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.

traviscross · 2025-03-10T07:48:24Z

cc @rust-lang/opsem @rust-lang/wg-llvm @wesleywiser @workingjubilee @chorman0773 @RalfJung @bjorn3 @ehuss

bjorn3 · 2025-05-28T08:54:21Z

compiler/rustc_feature/src/unstable.rs

@@ -612,8 +612,6 @@ declare_features! (
    (incomplete, ref_pat_eat_one_layer_2024_structural, "1.81.0", Some(123076)),
    /// Allows using the `#[register_tool]` attribute.
    (unstable, register_tool, "1.41.0", Some(66079)),
-    /// Allows the `#[repr(i128)]` attribute for enums.
-    (incomplete, repr128, "1.16.0", Some(56071)),


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

Probably. I did have a PR open to do so at #137592, but it didn't get reviewed before this PR was ready so I closed it in favour of this PR.

bjorn3 · 2025-05-28T09:01:00Z

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

@bors r=traviscross,bjorn3

bors · 2025-05-28T09:01:03Z

📌 Commit 30f13ca has been approved by traviscross,bjorn3

It is now in the queue for this repository.

…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

jieyouxu · 2025-05-28T13:50:03Z

I think you missed a feature gate in

rust/tests/ui/lint/lint-ctypes-enum.rs

Line 5 in 77101fe

#![feature(repr128)]

Rollup failure: #141688 (comment)

@bors r-

beetrees · 2025-05-28T14:16:39Z

Fixed with a rebase.

@rustbot ready

bjorn3 · 2025-05-28T14:31:31Z

@bors r=traviscross,bjorn3

bors · 2025-05-28T14:31:33Z

📌 Commit 467eeab has been approved by traviscross,bjorn3

It is now in the queue for this repository.

…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

Rollup of 7 pull requests Successful merges: - #125087 (Optimize `Seek::stream_len` impl for `File`) - #133823 (Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion) - #138285 (Stabilize `repr128`) - #139994 (add `CStr::display`) - #141477 (Path::with_extension: show that it adds an extension where one did no…) - #141533 (clean up old rintf leftovers) - #141693 (Subtree update of `rust-analyzer`) r? `@ghost` `@rustbot` modify labels: rollup

…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

Rollup of 8 pull requests Successful merges: - #125087 (Optimize `Seek::stream_len` impl for `File`) - #138285 (Stabilize `repr128`) - #139994 (add `CStr::display`) - #141477 (Path::with_extension: show that it adds an extension where one did no…) - #141533 (clean up old rintf leftovers) - #141690 (Add `rustc_diagnostic_item` to `sys::Mutex` methods) - #141693 (Subtree update of `rust-analyzer`) - #141702 (Add eholk to compiler reviewer rotation) r? `@ghost` `@rustbot` modify labels: rollup

rustbot assigned traviscross Mar 9, 2025

rustbot added T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. I-lang-nominated Nominated for discussion during a lang team meeting. labels Mar 9, 2025

beetrees mentioned this pull request Mar 9, 2025

Mark feature(repr128) as a complete feature #137592

Closed

rustbot added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Mar 9, 2025

beetrees mentioned this pull request Mar 9, 2025

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

Open

aDotInTheVoid removed A-rustdoc-search Area: Rustdoc's search feature T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Mar 9, 2025

This was referenced Mar 9, 2025

triagebot.toml: Don't label test/rustdoc-json as A-rustdoc-search #137958

Merged

triagebot.toml: Don't label test/rustdoc-json as A-rustdoc-search (… #138286

Merged

jieyouxu self-assigned this Mar 10, 2025

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Mar 10, 2025

rustbot assigned bjorn3 and unassigned RalfJung May 25, 2025

bjorn3 reviewed May 28, 2025

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 28, 2025

jieyouxu mentioned this pull request May 28, 2025

Rollup of 11 pull requests #141688

Closed

This comment was marked as resolved.

Sign in to view

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 28, 2025

tgross35 added the relnotes Marks issues that should be documented in the release notes of the next release. label May 28, 2025

Stabilise repr128

467eeab

beetrees force-pushed the repr128-stable branch from 30f13ca to 467eeab Compare May 28, 2025 14:15

rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label May 28, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 28, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 28, 2025

tgross35 mentioned this pull request May 28, 2025

Rollup of 7 pull requests #141707

Closed

tgross35 mentioned this pull request May 28, 2025

Rollup of 8 pull requests #141710

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Stabilize `repr128` #138285

Stabilize `repr128` #138285

beetrees commented Mar 9, 2025 •

edited by ehuss

Loading

Uh oh!

rustbot commented Mar 9, 2025

Uh oh!

traviscross commented Mar 10, 2025

Uh oh!

rfcbot commented Mar 10, 2025 •

edited

Loading

Uh oh!

traviscross commented Mar 10, 2025 •

edited

Loading

Uh oh!

bjorn3 May 28, 2025

Uh oh!

beetrees May 28, 2025

Uh oh!

bjorn3 commented May 28, 2025

Uh oh!

bors commented May 28, 2025

Uh oh!

jieyouxu commented May 28, 2025

Uh oh!

This comment was marked as resolved.

beetrees commented May 28, 2025

Uh oh!

bjorn3 commented May 28, 2025

Uh oh!

bors commented May 28, 2025

Uh oh!

Uh oh!

Stabilize repr128 #138285

Are you sure you want to change the base?

Stabilize repr128 #138285

Conversation

beetrees commented Mar 9, 2025 • edited by ehuss Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Stabilisation report

Uh oh!

rustbot commented Mar 9, 2025

Uh oh!

traviscross commented Mar 10, 2025

Uh oh!

rfcbot commented Mar 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

bjorn3 May 28, 2025

Choose a reason for hiding this comment

Uh oh!

beetrees May 28, 2025

Choose a reason for hiding this comment

Uh oh!

bjorn3 commented May 28, 2025

Uh oh!

bors commented May 28, 2025

Uh oh!

jieyouxu commented May 28, 2025

Uh oh!

This comment was marked as resolved.

beetrees commented May 28, 2025

Uh oh!

bjorn3 commented May 28, 2025

Uh oh!

bors commented May 28, 2025

Uh oh!

Uh oh!

Stabilize `repr128` #138285

Stabilize `repr128` #138285

beetrees commented Mar 9, 2025 •

edited by ehuss

Loading

rfcbot commented Mar 10, 2025 •

edited

Loading

traviscross commented Mar 10, 2025 •

edited

Loading