Exhaustiveness checker errors on unconstructible enum variant

[matprec]

use std::marker::PhantomData;

enum Void {}

enum Foo<T=()> {
    Bar,
    Baz,
    Phantom(PhantomData<T>, Void)
}

pub fn test(f: Foo) {
    match f {
        Foo::Bar => println!("Bar"),
        Foo::Baz => println!("Baz"),
    }
}

Playground

I expect this to work, since the Phantom case is not constructible, since it contains a Void type.

The exhaustiveness checker instead errors because it thinks that the Phantom case should be covered as well:

error[E0004]: non-exhaustive patterns: `Phantom(_, _)` not covered
  --> src/lib.rs:12:11
   |
5  | / enum Foo<T=()> {
6  | |     Bar,
7  | |     Baz,
8  | |     Phantom(PhantomData<T>, Void)
   | |     ------- not covered
9  | | }
   | |_- `Foo` defined here
...
12 |       match f {
   |             ^ pattern `Phantom(_, _)` not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms

error: aborting due to previous error

Meta

Happens on stable and nightly as of 2020-03-04

[hellow554]

But it's correct. Although it can't be constructed, you have to use _ => {} for an exhaustive match.
This construct can be used as a workaround for older compiler, that don't support the #[non_exhaustive] attribute.
So I think the complain from the compiler is valid?!

[matprec]

@hellow554 I don't think that this is a proper workaround for the #[non_exhaustive] attribute, since it doesn't forbid matching explicitly against the Phantom variant. The RFC cites #[doc(hidden)] in the How we do this today section.

[matprec]

I'd argue that this should be valid, since the error states its intention as "help: ensure that all possible cases are being handled" (emphasis mine), yet the Phantom variant is not "possible".

Of course, the error message could simply be adjusted, but i find it unintuitive having to create a case for a variant that simply cannot occur at runtime.

[Centril]

This compiles if you use #![feature(exhaustive_patterns)], so I'm closing in favor of #51085.