Empty match expressions can be ill-typed.

[michaelsproul]

I've been playing around with empty match expressions, which are only allowed if the type being matched on is empty, and I've noticed that it's possible to compile (seemingly) ill-typed code like the following:

enum Empty {}

fn main() {
    let x: &Empty = unsafe {
        &*(0 as *const Empty)
    };

    let y: u32 = match *x {};
    println!("{}", y);
}

I would have expected this not to compile as match *x {} can only sensibly evaluate to (), yet y has type u32. The compiler only reports that the variable y is unused.

$ rustc empty.rs
empty.rs:8:9: 8:10 warning: unused variable: `y`, #[warn(unused_variables)] on by default
empty.rs:8     let y: u32 = match *x {};

Running it on Linux x86_64 results in a segfault followed by an illegal instruction.

Some solutions I see are:

• Ensure empty match expressions have type unit ().
• Disallow empty match expressions entirely (although they could be useful in generated code).
• Do nothing.

[pnkfelix]

see also #12609 and #4499

[pnkfelix]

See the dialogue starting here in particular: #4499 (comment)

Essentially, it is a huge abuse of the system to transmute a value to an instance of an empty enum. Arguably we should assign a size to an empty enum that would ensure such transmutation does not occur. (in the past I have considered e.g. changing our internal size representation for types to be an Option<usize> instead of always assuming that all types have a size...)

I am actually halfway tempted to assign them the size usize::MAX right now. I bet that would essentially fix all attempts to expose these bugs. :)

[reem]

I don't actually think this is a bug - this code invokes undefined behavior in multiple ways, so it's ok that it segfaults.

Operations on unreachable values are themselves unreachable; operations on Void types, e.g. an empty match, can return any type, since, in a program without undefined behavior, they are always unreachable. cf. the type of std::intrinsics::unreachable.

[pnkfelix]

@reem right, well, i guess my point is that it would make it more obvious that the user is doing something bad, in a way that ... shouldn't ... break anything else?

[reem]

@pnkfelix imo it's actually useful for these operations to be any type, since it simplifies writing code that deals with empty "values" in branches-never-taken. That said, you could deal with this in a lot of different ways, so it's not a big deal if it becomes an error.

[steveklabnik]

I would imagine changing the size of an empty enum would require an RFC, and as @reem says, this is okay to segfault, so I'm gonna give it a close.