Stabilize 128-bit integers :tada: by mark-i-m · Pull Request #49101 · rust-lang/rust

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

s/repri128/repr128

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

s/repri128/repr128

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

nit: language feature repr128

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

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

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

Stray feature(i128) left behind.

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

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

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`. Closesrust-lang#56071Closesrust-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`. Closesrust-lang#56071Closesrust-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`. Closesrust-lang#56071Closesrust-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#56071Closesrust-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