[const-prop] Fix ICE calculating enum discriminant by wesleywiser · Pull Request #66960 · rust-lang/rust

wesleywiser · 2019-12-02T13:21:27Z

Fixes#66787

Different approach than #66857

r? @oli-obk
cc @RalfJung @eddyb

wesleywiser · 2019-12-02T23:56:40Z

I've pushed changes which I believe addresses all of the feedback so far. This is ready for review.

oli-obk · 2019-12-03T09:18:43Z

@bors r+

bors · 2019-12-03T09:18:45Z

📌 Commit 03460b3d7ecd3ab7ff0d52bf38d6663f5b77f3a6 has been approved by oli-obk

RalfJung · 2019-12-03T09:26:31Z

Let's fix those typos before landing.

@bors r-

RalfJung · 2019-12-03T11:00:54Z

The key point is that there's no alternative: there's no way to represent those variants in the given layout.

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 SetDiscriminant means) an uninhabited variant should never be reachable, as another uninhabited Operandmust'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)

(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.

Fixesrust-lang#66787

RalfJung · 2019-12-03T12:20:24Z

@bors r=oli-obk,RalfJung

bors · 2019-12-03T12:20:25Z

📌 Commit 0be80f2 has been approved by oli-obk,RalfJung

@oli-obk

…obk,RalfJung [const-prop] Fix ICE calculating enum discriminant Fixesrust-lang#66787 Different approach than rust-lang#66857 r? @oli-obk cc @RalfJung @eddyb

@oli-obk

…obk,RalfJung [const-prop] Fix ICE calculating enum discriminant Fixesrust-lang#66787 Different approach than rust-lang#66857 r? @oli-obk cc @RalfJung @eddyb

@ghost

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

@eddyb

…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

rust-highfive assigned oli-obk Dec 2, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 2, 2019

wesleywiser mentioned this pull request Dec 2, 2019
[const-prop] Fix ICE due to underflow when calculating enum discriminant #66857
Closed

eddyb reviewed Dec 2, 2019
View reviewed changes