Skip to content
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

fix Miri discriminant handling #63448

Merged
merged 6 commits into from
Sep 20, 2019
Merged

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Aug 10, 2019

This can be reviewed commit-by-commit fairly well.

The Miri side is at rust-lang/miri#903.

Fixes #62138

r? @eddyb @oli-obk

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 10, 2019
@eddyb
Copy link
Member

eddyb commented Aug 10, 2019

I'd prefer to block this on #63450.

@RalfJung RalfJung force-pushed the miri-discriminant branch 2 times, most recently from 90d692b to bc8cde5 Compare August 17, 2019 10:58
@RalfJung
Copy link
Member Author

I factored out the parts that are not blocked into a separate PR: #63658.

bors added a commit that referenced this pull request Aug 17, 2019
Refactor Miri ops (unary, binary) to have more types

This is the part of #63448 that is just a refactoring. It helps that PR by making it easier to perform machine arithmetic.

r? @oli-obk @eddyb
@JohnCSimon
Copy link
Member

Ping from triage:
This PR has sat idle for over a week, can you please post your status? Thanks.
@RalfJung @eddyb

@RalfJung
Copy link
Member Author

@eddyb is blocking this on #63450. That's fine for me as long as that does not take too long.

@RalfJung
Copy link
Member Author

@eddyb #63450 does not seem to be moving anywhere. Could you explain why it is better to leave this Miri bug unfixed?

@JohnCSimon JohnCSimon added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Sep 7, 2019
@JohnCSimon
Copy link
Member

Ping from triage
@RalfJung @eddyb Still blocked on #63450 ...

@RalfJung
Copy link
Member Author

@eddyb noticed that doing all arithmetic using machine operations at discriminant type is also not correct, so now this does the variant idx computations on the host (checked so they do not overflow).

@RalfJung RalfJung removed the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Sep 16, 2019
@RalfJung
Copy link
Member Author

RalfJung commented Sep 16, 2019

@eddyb also agreed to no longer block this on #63450

@RalfJung
Copy link
Member Author

I should also mention, tests will be added to Miri. My naive attempt at turning that into CTFE tests failed. @oli-obk is it possible to test this with current CTFE so that we have an in-tree test?

@oli-obk
Copy link
Contributor

oli-obk commented Sep 16, 2019

is it possible to test this with current CTFE so that we have an in-tree test?

Make it a -Zunleash-the-miri-inside-of-you test 😈

@RalfJung
Copy link
Member Author

Make it a -Zunleash-the-miri-inside-of-you test

I think that actually worked :D

// Then computing the absolute variant idx should not overflow any more.
let variant_index = variants_start
.checked_add(variant_index_relative)
.expect("oveflow computing absolute variant idx");
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if this can overflow when it's the dataful variant. Still, ICE > silently doing the wrong thing.

.checked_add(variant_index_relative)
.expect("oveflow computing absolute variant idx");
// Check if this is in the range that indicates an actual discriminant.
if variants_start <= variant_index && variant_index <= variants_end {
Copy link
Member

@eddyb eddyb Sep 18, 2019

Choose a reason for hiding this comment

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

Oh wait you can just compare variant_index_relative against variants_end - variants_start, and then you can move the addition inside the "niche" side of the if.

Copy link
Member Author

Choose a reason for hiding this comment

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

So the if should change to variant_index_relative <= variants_end - variants_start you say?

What is the "niche side of the if"?

let variants_start = niche_variants.start().as_u32();
let variant_index_relative = variant_index.as_u32()
.checked_sub(variants_start)
.expect("overflow computing relative variant idx");
Copy link
Member

Choose a reason for hiding this comment

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

I think this is fine because this is a "niche" variant.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure but is there any reason not to ICE if this overflows anyway?

let discr_val = self.binary_op(
mir::BinOp::Add,
variant_index_relative_val,
niche_start_val,
)?;
Copy link
Member

Choose a reason for hiding this comment

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

I wonder how much this matters - you just need to truncate the result, I think? Either way, the symmetry with reading is probably fine.

@eddyb
Copy link
Member

eddyb commented Sep 18, 2019

r=me with #63448 (comment) fixed.

@RalfJung
Copy link
Member Author

r=me with #63448 (comment) fixed.

I think I did this -- and the tests are all passing.
@bors r=eddyb

@bors
Copy link
Contributor

bors commented Sep 19, 2019

📌 Commit 1de533a has been approved by eddyb

@bors 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 Sep 19, 2019
@bors
Copy link
Contributor

bors commented Sep 19, 2019

⌛ Testing commit 1de533a with merge b480f068c8efc171da04e5e132310df0778ff4b1...

@bors
Copy link
Contributor

bors commented Sep 19, 2019

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 19, 2019
@mati865
Copy link
Contributor

mati865 commented Sep 19, 2019

cc @pietroalbini ^^ many jobs were stared very late and some still are waiting for the agent

@RalfJung
Copy link
Member Author

@bors retry

@bors 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 Sep 19, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 19, 2019
fix Miri discriminant handling

This can be reviewed commit-by-commit fairly well.

The Miri side is at rust-lang/miri#903.

Fixes rust-lang#62138

r? @eddyb @oli-obk
bors added a commit that referenced this pull request Sep 19, 2019
Rollup of 6 pull requests

Successful merges:

 - #63448 (fix Miri discriminant handling)
 - #64592 (Point at original span when emitting unreachable lint)
 - #64601 (Fix backticks in documentation)
 - #64606 (Remove unnecessary `mut` in doc example)
 - #64611 (rustbuild: Don't package libstd twice)
 - #64613 (rustbuild: Copy crate doc files fewer times)

Failed merges:

r? @ghost
bors added a commit that referenced this pull request Sep 19, 2019
Rollup of 6 pull requests

Successful merges:

 - #63448 (fix Miri discriminant handling)
 - #64592 (Point at original span when emitting unreachable lint)
 - #64601 (Fix backticks in documentation)
 - #64606 (Remove unnecessary `mut` in doc example)
 - #64611 (rustbuild: Don't package libstd twice)
 - #64613 (rustbuild: Copy crate doc files fewer times)

Failed merges:

r? @ghost
@bors bors merged commit 1de533a into rust-lang:master Sep 20, 2019
bors added a commit to rust-lang/miri that referenced this pull request Sep 20, 2019
@RalfJung RalfJung deleted the miri-discriminant branch September 28, 2019 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Miri/CTFE discriminant computation happens at the wrong type
7 participants