Stabilize 128-bit integers 🎉 #49101

mark-i-m · 2018-03-17T01:17:30Z

EDIT: This should be merged only after the following have been merged:

rust-highfive · 2018-03-17T01:17:33Z

(rust_highfive has picked a reviewer for you, use r? to override)

mark-i-m · 2018-03-17T01:31:52Z

What does this tidy error mean?

tidy error: /checkout/src/libcore/num/mod.rs:3961: mismatches to previous in: ["stability level", "since", "tracking issue"]

mark-i-m · 2018-03-17T02:21:39Z

I'm also getting this error:

   Compiling std_unicode v0.0.0 (file:///nobackup/rust/src/libstd_unicode)
error: this feature has been stable since 1.26.0. Attribute no longer needed
  --> rustc/compiler_builtins_shim/../../libcompiler_builtins/src/lib.rs:15:12
   |
15 | #![feature(i128_type)]
   |            ^^^^^^^^^
   |
note: lint level defined here
  --> rustc/compiler_builtins_shim/../../libcompiler_builtins/src/lib.rs:1:31
   |
1  | #![cfg_attr(not(stage0), deny(warnings))]
   |                               ^^^^^^^^
   = note: #[deny(stable_features)] implied by #[deny(warnings)]

error: aborting due to previous error

error: Could not compile `compiler_builtins`.

PlasmaPower · 2018-03-17T03:11:25Z

For the latter error, it looks like libcompiler_builtins/src/lib.rs of the std_unicode crate has #![feature(i128_type)] on line 15 (because it was unstable). Now that it's stable, it's erroring, because it also has #![deny(warnings)] and the compiler warns when you #![feature()] an already stable feature.

PlasmaPower · 2018-03-17T03:19:24Z

Here's the line: https://github.com/rust-lang-nursery/compiler-builtins/blob/266ea0740a5bdd262a38bbd88fb55fc3d2a7a96e/src/lib.rs#L15

Unfortunately it's in a submodule (different repository) so I don't think there's a good way to simultaneously change them.

goodmanjonathan · 2018-03-17T04:50:41Z

src/doc/unstable-book/src/language-features/repr128.md

@@ -0,0 +1,18 @@
+# `repri128`


s/repri128/repr128

goodmanjonathan · 2018-03-17T04:51:37Z

src/libsyntax/diagnostic_list.rs

@@ -261,10 +264,11 @@ If you're using a nightly version of rustc, just add the corresponding feature
 to be able to use it:

 ```
-#![feature(i128)]
+#![feature(repri128)]


s/repri128/repr128

goodmanjonathan · 2018-03-17T04:52:50Z

src/libsyntax/diagnostic_list.rs

@@ -250,7 +250,10 @@ An unstable feature was used.
 Erroneous code example:

 ```compile_fail,E658
-let x = ::std::u128::MAX; // error: use of unstable library feature 'i128'
+#[repr(u128)] // error: use of unstable library feature 'i128'


nit: language feature repr128

goodmanjonathan · 2018-03-17T04:53:58Z

src/test/ui/error-codes/E0658.stderr

@@ -4,7 +4,7 @@ error[E0658]: use of unstable library feature 'i128' (see issue #35118)
 LL |     let _ = ::std::u128::MAX; //~ ERROR E0658
   |             ^^^^^^^^^^^^^^^^
   |
-   = help: add #![feature(i128)] to the crate attributes to enable
+   = help: add #![feature(repri128)] to the crate attributes to enable


s/repri128/repr128

Er, shouldn't this test be testing another feature now :P

Yeah, the whole stderr needs to change... I will fix this one after I get the rest compiling successfully.

goodmanjonathan · 2018-03-17T05:00:47Z

src/test/ui/feature-gate-i128_type2.rs

@@ -10,20 +10,20 @@

 // gate-test-i128_type



Why not remove the i128_type tests?

I left this one as a test for the repr128 gate.

Oh, it looks like there is already a test for that.

goodmanjonathan · 2018-03-17T05:01:42Z

src/test/run-pass/saturating-float-casts.rs

@@ -11,7 +11,7 @@
 // Tests saturating float->int casts. See u128-as-f32.rs for the opposite direction.
 // compile-flags: -Z saturating-float-casts

-#![feature(test, i128, i128_type, stmt_expr_attributes)]
+#![feature(test, i128, stmt_expr_attributes)]


Stray feature(i128) left behind.

goodmanjonathan · 2018-03-17T05:02:38Z

src/test/run-pass/u128-as-f32.rs

@@ -10,7 +10,7 @@

 // ignore-emscripten u128 not supported

-#![feature(test, i128, i128_type)]
+#![feature(test, i128)]


Stray feature(i128) left behind.

goodmanjonathan · 2018-03-17T05:12:10Z

Regarding the first tidy failure, it looks like you forgot to change a few items to #[stable] starting on line 3961 of that file.

est31 · 2018-03-17T08:14:54Z

src/test/ui/feature-gate-i128_type2.rs

@@ -10,20 +10,20 @@

 // gate-test-i128_type


You'll probably have to remove this line.

Thanks :) I removed the test altogether since there is already a test for the repr128 gate.

petrochenkov · 2018-03-17T11:02:11Z

r? @nagisa or @alexcrichton

mark-i-m · 2018-03-17T16:48:03Z

Thanks @goodmanjonathan and @PlasmaPower ! I am fixing those things now :)

mark-i-m · 2018-03-17T16:57:36Z

Hmm... I am still getting this tidy error:

tidy error: /nobackup/rust/src/libcore/num/mod.rs:3961: mismatches to previous in: ["stability level", "since", "tracking issue"]

But I fixed that line?

mark-i-m · 2018-03-17T19:31:44Z

Re: #49101 (comment)

How do I actually fix this? Every time ./x.py updates submodules my dirty changes get reverted...

PlasmaPower · 2018-03-17T19:42:48Z

I'd get the change on a different branch or the submodule's repository, then change the submodule's to point to that branch. I'm not sure if that's the right way to do this though.

kennytm · 2018-03-17T20:20:28Z

@mark-i-m Add [build] submodules = false to your config.toml to disable automatic submodule update.

(Using __git_ps1 is highly recommended to visualize stale submodules after auto-update is disabled.)

nagisa · 2018-03-17T22:51:21Z

I’ll review this after I get some sleep.

mark-i-m · 2018-03-18T01:37:52Z

Travis build is now failing because of the compiler_builtins error. Should I make a PR to that repo?

mark-i-m · 2018-03-18T02:26:31Z

Ok, I think the compiler_builtins error should be the last thing stopping this PR.

mark-i-m · 2018-03-18T02:39:02Z

Made a PR on compiler_builtins

mark-i-m · 2018-03-26T15:19:06Z

@nagisa Travis is passing again. nth try is the charm?

kennytm · 2018-03-26T15:24:25Z

@bors r=nagisa

bors · 2018-03-26T15:24:26Z

📌 Commit 140bf94 has been approved by nagisa

bors · 2018-03-26T18:41:44Z

⌛ Testing commit 140bf94 with merge 188e693...

Stabilize 128-bit integers 🎉 cc #35118 EDIT: This should be merged only after the following have been merged: - [x] rust-lang/compiler-builtins#236 - [x] rust-lang/book#1230

bors · 2018-03-26T21:21:28Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nagisa
Pushing 188e693 to master...

Tom-Phinney · 2018-05-28T04:07:54Z

FWIW, here are additional files in rustc that as of 2018.05.12 did not handle usize == u128, which will be needed by RISC-V with RV128I option when LLVM or some other backend supports it. The grep string (between « and ») was «#[cfg(target_pointer_width = "(16|32|64|128)")]»

lib_alloc/vec_deque.rs
libcore/fmt/num.rs
libcore/iter/range.rs
libcore/num/mod.rs
libcore/num/wrapping.rs
libcore/tests/hash/sip.rs
libcore/tests/iter.rs
libcore/tests/mem.rs
librustc_data_structures/fx.rs
libserialize/leb128.rs
sys_common/backtrace.rs
test/compile-fail/huge-enum.rs
test/compile-fail/issue-17913.rs
test/compile-fail/int-exceeding-bitshifts2.rs
test/run-pass/const-negation.rs
test/run-pass/enum-discrim-autosizing.rs
test/run-pass/extern-types-pointer-cast.rs
test/run-pass/huge-largest-array.rs
test/run-pass/issue-2895.rs
test/run-pass/num-wrapping.rs
test/run-pass/struct-return.rs
test/run-pass/vec-fixed-length.rs
test/run-pass/wrapping_int_api.rs

est31 · 2018-05-28T04:12:36Z

@Tom-Phinney it would be best to file an issue about this as inside this PR thread this is likely going to get lost.

…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

Rollup merge of #138285 - beetrees:repr128-stable, r=traviscross,bjorn3 Stabilize `repr128` ## Stabilisation report The `repr128` feature ([tracking issue](#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 #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 #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 #56071 Closes rust-lang/reference#1368 r? lang ```@rustbot``` label +I-lang-nominated +T-lang

rust-highfive assigned petrochenkov Mar 17, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 17, 2018

goodmanjonathan reviewed Mar 17, 2018

View reviewed changes

src/doc/unstable-book/src/language-features/repr128.md Outdated

@@ -0,0 +1,18 @@

# `repri128`

Copy link

Contributor

goodmanjonathan Mar 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/repri128/repr128

goodmanjonathan reviewed Mar 17, 2018

View reviewed changes

est31 reviewed Mar 17, 2018

View reviewed changes

rust-highfive assigned nagisa and unassigned petrochenkov Mar 17, 2018

mark-i-m changed the title ~~[WIP] Stabilize 128-bit integers!~~ Stabilize 128-bit integers 🎉 Mar 18, 2018

mark-i-m mentioned this pull request Mar 18, 2018

i128 is being stabilized rust-lang/compiler-builtins#235

Merged

mark-i-m added 5 commits March 26, 2018 08:37

Fix e0658 ui test

afc9890

Remove library feature test

ec98718

Update to master of libcompiler_builtins

66c8cdb

did i get it right now?

6b625b3

fix last two tidy

140bf94

mark-i-m force-pushed the stabilize_i128 branch from e378466 to 140bf94 Compare March 26, 2018 13:38

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 26, 2018

bors mentioned this pull request Mar 26, 2018

AST: Give spans to all identifiers #49154

Merged

bors merged commit 140bf94 into rust-lang:master Mar 26, 2018

bors mentioned this pull request Mar 26, 2018

Stabilize TryFrom / TryInto, and tweak impls for integers #49305

Merged

est31 mentioned this pull request Mar 27, 2018

Compile with stable Rust rwf2/Rocket#19

Closed

11 tasks

tirkarthi mentioned this pull request May 16, 2018

128 bit integers are stable with Rust 1.26 rust-lang/book#1363

Closed

hcpl mentioned this pull request May 27, 2018

Updating to v1.0.62 cause to error "128-bit type is unstable" serde-rs/serde#1291

Closed

hcpl mentioned this pull request May 29, 2018

docs.rs for dependent crates seems broken serde-rs/serde#1295

Closed

mark-i-m deleted the stabilize_i128 branch November 14, 2018 16:40

beetrees mentioned this pull request Mar 9, 2025

Stabilize repr128 #138285

Merged

Stabilize 128-bit integers 🎉 #49101

Stabilize 128-bit integers 🎉 #49101

Uh oh!

Conversation

mark-i-m commented Mar 17, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Mar 17, 2018

Uh oh!

mark-i-m commented Mar 17, 2018

Uh oh!

mark-i-m commented Mar 17, 2018

Uh oh!

PlasmaPower commented Mar 17, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PlasmaPower commented Mar 17, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goodmanjonathan commented Mar 17, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Mar 17, 2018

Uh oh!

mark-i-m commented Mar 17, 2018

Uh oh!

mark-i-m commented Mar 17, 2018

Uh oh!

mark-i-m commented Mar 17, 2018

Uh oh!

PlasmaPower commented Mar 17, 2018

Uh oh!

kennytm commented Mar 17, 2018

Uh oh!

nagisa commented Mar 17, 2018

Uh oh!

mark-i-m commented Mar 18, 2018

Uh oh!

mark-i-m commented Mar 18, 2018

Uh oh!

mark-i-m commented Mar 18, 2018

Uh oh!

mark-i-m commented Mar 26, 2018

Uh oh!

kennytm commented Mar 26, 2018

Uh oh!

bors commented Mar 26, 2018

Uh oh!

bors commented Mar 26, 2018

Uh oh!

bors commented Mar 26, 2018

Uh oh!

Tom-Phinney commented May 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

est31 commented May 28, 2018

mark-i-m commented Mar 17, 2018 •

edited

Loading

PlasmaPower commented Mar 17, 2018 •

edited

Loading

Tom-Phinney commented May 28, 2018 •

edited

Loading