Cannot write integer literal for the minimum i128 (-0x8000_0000_0000_0000_0000_0000_0000_0000i128) #38987

Closed
kennytm opened this Issue Jan 11, 2017 · 2 comments

Projects

None yet

2 participants

@kennytm
Contributor
kennytm commented Jan 11, 2017

Test case:

#![feature(i128_type)]
fn main() {
    -0x8000_0000_0000_0000i64;  // ok
    -0x8000_0000_0000_0000_0000_0000_0000_0000i128; // Error: attempt to negate with overflow
}

Gives error:

error[E0080]: constant evaluation error
 --> foo.rs:4:5
  |
4 |     -0x8000_0000_0000_0000_0000_0000_0000_0000i128; // Error: attempt to negate with overflow
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to negate with overflow

error: aborting due to previous error

It should compiles fine and the constant should produce the same value as i128::MIN.

For comparison the minimum i64 compiles fine with no warnings.

$ rustc -vV
rustc 1.16.0-nightly (47c8d9fdc 2017-01-08)
binary: rustc
commit-hash: 47c8d9fdcf2e6502cf4ca7d7f059fdc1a2810afa
commit-date: 2017-01-08
host: x86_64-apple-darwin
release: 1.16.0-nightly
LLVM version: 3.9
@est31
Contributor
est31 commented Jan 11, 2017

cc @nagisa
cc #35118

@est31
Contributor
est31 commented Jan 11, 2017

I'd want to give a try on this.

@nagisa nagisa added a commit to nagisa/rust that referenced this issue Jan 11, 2017
@nagisa nagisa Fix two const-eval issues related to i128 negation
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.

The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.

Fixes #38987
ec79a6d
@nagisa nagisa added a commit to nagisa/rust that referenced this issue Jan 11, 2017
@nagisa nagisa Fix two const-eval issues related to i128 negation
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.

The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.

Fixes #38987
e97f104
@bors bors added a commit that referenced this issue Jan 14, 2017
@bors bors Auto merge of #38992 - nagisa:i128-minvallit, r=eddyb
Fix two const-eval issues related to i128 negation

First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.

The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.

Fixes #38987
93e70ec
@bors bors closed this in #38992 Jan 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment