ICE with zero-arm alt, no matter the type. Also unsafe pointers.

[bblum]

All of the following programs (edit: not the second) produce 'Assertion pats.is_not_empty() failed', src/rustc/middle/check_alt.rs:80

This one should give a nonexhaustive error:

fn main() {
    alt () { } 
}

This one should compile and crash at runtime:

enum bottom { }

fn main() {
    let x = ptr::addr_of(()) as *bottom;
    alt unsafe { *x } { }
}

and I don't have the slightest idea what this one should do:

enum bottom { } 

fn main() {
    let x = ptr::addr_of(()) as *bottom;
    alt x { } 
}

Probably related #3037. The code in that bug compiles but it seems like the only zero-arm alt that can compile.

[nikomatsakis]

my opinion: alt foo {} should translate to (), but the bugs in exhaustiveness checking ought to be fixed

[bblum]

erm, actually, my mistake. The second program produces copying a noncopyable value on the *x.

[nikomatsakis]

I thought more about this. Now I think I was wrong. There are two things that should happen (one of which I think already does):

1. Exhaustiveness checking should always consider *T to be inhabited, because it might be NULL
2. alt foo {}, presuming it passes exhaustiveness checking, should translate to a simple fail.

Basically, alt is defined to match an arm and execute its code. If no arm matches, alt is defined to fail. Exhaustiveness checking guarantees that fail cannot happen---barring unsafe code. And, barring unsafe code, it is impossible to produce an instance of an empty enum, therefore, we can generate the fail safe in the knowledge it will never execute.

The only realistic scenario where this might matter I can come up with is auto-generated code, where it might happen that in some situations an empty enum is produced, probably corresponding to some case in the generated code that can never happen (a protocol state which can never be entered or what have you). In that case, generating a fail is the right to do: it's essentially an assertion failure, "The impossible happened!"

[catamorphism]

@nikomatsakis Your point (2) is what the compiler already does (well, it generates a fail with a more specific message). Obviously, (1) needs to be implemented.

[catamorphism]

I fixed case (1). Case (3) already behaves correctly (non-exhaustive pattern error), and case (2) gets rejected with a non-copyable error, as @bblum pointed out. If you have another version of case (2) that illustrates what you want, feel free to open a new bug, but I think what I'm checking in is good enough for now.

[catamorphism]

Fixed in c0140f5