Skip to content

Fix two const-eval issues related to i128 negation #38992

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 14, 2017

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Jan 11, 2017

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

@nagisa
Copy link
Member Author

nagisa commented Jan 11, 2017

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned nikomatsakis Jan 11, 2017
@rust-highfive
Copy link
Contributor

r? @nikomatsakis

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

@eddyb
Copy link
Member

eddyb commented Jan 11, 2017

Missing feature gate.

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 rust-lang#38987
@nagisa
Copy link
Member Author

nagisa commented Jan 11, 2017

Fixed.

@eddyb
Copy link
Member

eddyb commented Jan 11, 2017

@bors r+

@bors
Copy link
Collaborator

bors commented Jan 11, 2017

📌 Commit e97f104 has been approved by eddyb

@bors
Copy link
Collaborator

bors commented Jan 14, 2017

⌛ Testing commit e97f104 with merge 93e70ec...

bors added a commit that referenced this pull request Jan 14, 2017
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
@bors
Copy link
Collaborator

bors commented Jan 14, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 93e70ec to master...

@bors bors merged commit e97f104 into rust-lang:master Jan 14, 2017
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Jan 16, 2017
bors added a commit that referenced this pull request Jan 17, 2017
Fix stage 1 tests broken because i128 doesn't work in stage 1

Broken by #38992.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot write integer literal for the minimum i128 (-0x8000_0000_0000_0000_0000_0000_0000_0000i128)
5 participants