[const-prop] Fix ICE calculating enum discriminant #66960
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
eddyb
reviewed
Dec 2, 2019
RalfJung
reviewed
Dec 2, 2019
RalfJung
reviewed
Dec 2, 2019
RalfJung
reviewed
Dec 2, 2019
RalfJung
reviewed
Dec 2, 2019
wesleywiser
force-pushed
the
fix_66787_take2
branch
from
6e5138f
to
25da0fb
Compare
|
I've pushed changes which I believe addresses all of the feedback so far. This is ready for review. |
This comment has been minimized.
This comment has been minimized.
wesleywiser
force-pushed
the
fix_66787_take2
branch
from
25da0fb
to
03460b3
Compare
|
@bors r+ |
|
📌 Commit 03460b3d7ecd3ab7ff0d52bf38d6663f5b77f3a6 has been approved by |
bors
added
S-waiting-on-bors
RalfJung
reviewed
Dec 3, 2019
RalfJung
reviewed
Dec 3, 2019
RalfJung
reviewed
Dec 3, 2019
|
Let's fix those typos before landing. @bors r- |
bors
added
S-waiting-on-author
wesleywiser
force-pushed
the
fix_66787_take2
branch
from
03460b3
to
414f84d
Compare
RalfJung
reviewed
Dec 3, 2019
src/librustc_mir/interpret/place.rs
Outdated
Comment on lines
1042
to
1043
| // Layout computation excludes uninhabited variants from consideration | ||
| // so this checks that the `variant_index` is valid. |
There was a problem hiding this comment.
The key point is that there's no alternative: there's no way to represent those variants in the given layout.
There was a problem hiding this comment.
I feel like there's been a lot of muddying the waters on "variant_index validity".
It's always valid, it's always in range, it's impossible for it to not be a variant (despite what has been said wrt the comments lower down).
Also, for Multiple, the variants vec always includes all variants declared in the enum.
What needs to be handled here is "the variant is uninhabited" i.e. unrepresented.
This means two things, not just one (another source of confusion):
- there is no tag/niche allocated for it, so the best you could do is write undef over the tag/niche
- fully initializing (which is what
SetDiscriminantmeans) an uninhabited variant should never be reachable, as another uninhabitedOperandmust've been evaluated for at least one of the fields, so this should be some sort of error (I think @RalfJung is right that this is technically an "invalid program" situation)
There was a problem hiding this comment.
(of course the PR was updated while I was trying to post that comment, heh)
I think the new form of the comment seems fine, but I'd wait until @RalfJung also agrees, to proceed.
wesleywiser
force-pushed
the
fix_66787_take2
branch
from
414f84d
to
0be80f2
Compare
|
@bors r=oli-obk,RalfJung |
|
📌 Commit 0be80f2 has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Dec 3, 2019
…obk,RalfJung [const-prop] Fix ICE calculating enum discriminant Fixes rust-lang#66787 Different approach than rust-lang#66857 r? @oli-obk cc @RalfJung @eddyb
Centril
added a commit
to Centril/rust
that referenced
this pull request
Dec 3, 2019
…obk,RalfJung [const-prop] Fix ICE calculating enum discriminant Fixes rust-lang#66787 Different approach than rust-lang#66857 r? @oli-obk cc @RalfJung @eddyb
bors
added a commit
that referenced
this pull request
Dec 3, 2019
Rollup of 7 pull requests Successful merges: - #66750 (Update the `wasi` crate for `wasm32-wasi`) - #66878 (Move Sessions into (new) librustc_session) - #66903 (parse_enum_item -> parse_enum_variant) - #66951 (miri: add throw_machine_stop macro) - #66957 (Change Linker for x86_64-fortanix-unknown-sgx target to rust-lld) - #66960 ([const-prop] Fix ICE calculating enum discriminant) - #66973 (Update the minimum external LLVM to 7) Failed merges: r? @ghost
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Dec 6, 2019
…le, r=oli-obk codegen "unreachable" for invalid SetDiscriminant Follow-up from rust-lang#66960. I also realized I don't understand our policy for using `abort` vs `unreachable`. AFAIK `abort` is safe to call and just aborts the process, while `unreachable` is UB. But sometimes we use both, like here https://github.com/rust-lang/rust/blob/d825e35ee8325146e6c175a4c61bcb645b347d5e/src/librustc_codegen_ssa/mir/block.rs#L827-L828 and here https://github.com/rust-lang/rust/blob/d825e35ee8325146e6c175a4c61bcb645b347d5e/src/librustc_codegen_ssa/mir/block.rs#L264-L265 The second case is even more confusing because that looks like an unreachable `return` to me, so why would we codegen a safe abort there? r? @eddyb Cc @oli-obk
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #66787
Different approach than #66857
r? @oli-obk
cc @RalfJung @eddyb