RFC 2008: Uninhabitedness fixes for enum variants and tests

[davidtwco]

Part of #44109.

At the request of @Centril, this PR adds tests asserting that uninhabited non-exhaustive types are considered inhabited in extern crates. In adding these tests, I fixed an oversight in the implementation of RFC 2008 on enum variants that resulted in non-exhaustive enum variants being considered uninhabited in extern crates.

Before this PR, these lines would error:

// extern crate
pub enum UninhabitedVariants {
    #[non_exhaustive] Tuple(!),
    #[non_exhaustive] Struct { x: ! }
}

pub enum PartiallyInhabitedVariants {
    Tuple(u8),
    #[non_exhaustive] Struct { x: ! }
}

// current crate
match uninhabited_variant() /* fn() -> Option<UninhabitedVariants> */ {
    Some(_x) => (), //~ ERROR unreachable pattern
    None => (),
}

while let PartiallyInhabitedVariants::Struct { x, .. } = partially_inhabited_variant() /* fn() -> PartiallyInhabitedVariants */ {
    //~^ ERROR unreachable pattern
}

cc @Centril
r? @petrochenkov

[Centril]

Love the barrage of tests! :)

[petrochenkov]

I don't think I understand the examples.

pub enum UninhabitedVariants {
    #[non_exhaustive] Struct { x: ! }
}

The type already has a public uninhabited field, so no amount of added fields will make it inhabited, so it's publicly uninhabited for this crate or for other crates, doesn't matter.

#[non_exhaustive] on enums can affect inhabitedness, because new variants can make the enum inhabited, but for structs/variants that's not the case.

[Centril]

but for structs/variants that's not the case.

If you have exhaustive_patterns, then the type system would let you match x: UninhabitedStruct {} on an otherwise uninhabited struct or variant (at least with rust-lang/rfcs#2593 for the latter). However, until we have collectively decided otherwise, I think #[non_exhaustive] should prevent that in other crates. It might be the case that we use a different mechanism in the end, but let's be conservative for now and allow exhaustive pattern matching deliberately in these cases. The use case for this is when you have something like a struct TcpStream(!); on some platforms where it cannot be constructed and where it can be constructed on other platforms.

[petrochenkov]

#[non_exhaustive] implies that new fields can be added to a struct, so here are the possible cases of new fields affecting the struct inhabitedness as it's seen from other crates:

// The struct is externally inhabited, the field addition doesn't change that
struct S { a: PrivDoesntmatter } -> struct S { a: PrivDoesntmatter, b: PrivDoesntmatter }

// The struct is externally inhabited, the field addition doesn't change that
struct S { a: PrivDoesntmatter } -> struct S { a: PrivDoesntmatter, pub b: PubInhabited }

// The struct is externally inhabited, the field addition changes that
struct S { a: PrivDoesntmatter } -> struct S { a: PrivDoesntmatter, pub b: PubUninhabited }

---

// The struct is externally inhabited, the field addition doesn't change that
struct S { pub a: PubInhabited } -> struct S { pub a: PubInhabited, b: PrivDoesntmatter }

// The struct is externally inhabited, the field addition doesn't change that
struct S { pub a: PubInhabited } -> struct S { pub a: PubInhabited, pub b: PubInhabited }

// The struct is externally inhabited, the field addition changes that
struct S { pub a: PubInhabited } -> struct S { pub a: PubInhabited, pub b: PubUninhabited }

---

// The struct is externally uninhabited, the field addition doesn't change that
struct S { pub a: PubUninhabited } -> struct S { pub a: PubInhabited, b: PrivDoesntmatter }

// The struct is externally uninhabited, the field addition doesn't change that
struct S { pub a: PubUninhabited } -> struct S { pub a: PubInhabited, pub b: PubInhabited }

// The struct is externally uninhabited, the field addition doesn't change that
struct S { pub a: PubUninhabited } -> struct S { pub a: PubInhabited, pub b: PubUninhabited }

The situation with variants is a bit simpler since they don't have private fields:

// The variant is externally inhabited, the field addition doesn't change that
variant S { pub a: PubInhabited } -> variant S { pub a: PubInhabited, pub b: PubInhabited }

// The variant is externally inhabited, the field addition changes that
variant S { pub a: PubInhabited } -> variant S { pub a: PubInhabited, pub b: PubUninhabited }

---

// The variant is externally uninhabited, the field addition doesn't change that
variant S { pub a: PubUninhabited } -> variant S { pub a: PubInhabited, pub b: PubInhabited }

// The variant is externally uninhabited, the field addition doesn't change that
variant S { pub a: PubUninhabited } -> variant S { pub a: PubInhabited, pub b: PubUninhabited }

So, if #[non_exhaustive] does nothing with inhabitedness, then adding a new public uninhabited field to a previously inhabited struct or variant is a breaking change (kind of, unreachable_patterns is only a lint).

Is adding a new public uninhabited field to something previously inhabited a realistic scenario?

(The struct TcpStream(!); is already covered by privacy, doesn't need #[non_exhaustive].)

[petrochenkov]

Any other properties that can change if a new field is added?
Something Drop-related perhaps?

[petrochenkov]

Ok, I had some time to digest this and I agree that if addition of a new public uninhabited field can break code, then #[non_exhaustive] should prevent that.

[davidtwco]

@petrochenkov I've fixed all of your suggestions. I can't relabel from S-waiting-on-author to S-waiting-on-review.

[petrochenkov]

@bors r+

[bors]

📌 Commit f9e4da04abc8e97cd1ae9468b6b4eff67e1c9c64 has been approved by petrochenkov

[bors]

⌛ Testing commit f9e4da04abc8e97cd1ae9468b6b4eff67e1c9c64 with merge 1865e9b9959474dd84d33416372a3e6aadc7224e...

[bors]

💔 Test failed - status-appveyor

[davidtwco]

I've rebased this and updated the tests with longer names to use the same fix as #60648 to avoid spurious failures on Windows.

[petrochenkov]

Legitimate error - file paths are too long (ui\rfc-2008-non-exhaustive\uninhabited\indirect_match_with_exhaustive_patterns_same_crate.rs).

[petrochenkov]

@bors r+

[bors]

📌 Commit 1f0fb03 has been approved by petrochenkov