feature-gate uninhabited checks

[nikomatsakis]

Per the discussion on internals, we want to ensure that the recent improvements to uninhabited types are feature-gated. There was #39151, but that only applies to &Void, whereas it seems prudent to try to feature-gate the changes to uninhabited checks more broadly.

cc @eddyb @arielb1 @canndrew

[nikomatsakis]

triage: P-high

[nikomatsakis]

Marking as P-high because we want to reach a state we are all happy with before next beta.

[nikomatsakis]

I'm not sure on just what the algorithm did before the change -- I believe that it specifically handled a case where you wrote match foo { } and foo was considered uninhabited? So if we wanted to reproduce just that behavior, we would disable the "new" uninhabited check, but retain the older one?

The main case I am wondering about is stuff like where a Void is found inside a field that may (or may not) be accessed. e.g., is (i32, Void) uninhabited? Seems like that is not entirely clear in unsafe code (for same reason as &*). But I have to refresh my memory for the conversation and don't have a chance just now.

[arielb1]

The old algorithm regarded all types as inhabited, except that an empty match was special cased.

About uninhabitableness: I am quite sure you should not be having invalid values. Stuff like nonstandard booleans in an (u32, bool) will cause UB by LLVM range assert even today. That means that (i32, Void) is truly uninhabited.

[djzin]

I find it helpful to think of ! / Void as not being a zero-sized type; rather it could be thought of as having "negative infinity" size, being log(0) bits in size. From this perspective (i32, Void) doesn't "feel" like it should exist since you are juxtaposing a type with 32 bits next to negative infinity bits, and the infinite wins out.

[nikomatsakis]

Fixed by #39151

[nikomatsakis]

Er, #39290

[nikomatsakis]

Not yet landed, so I'll leave it open.

[nikomatsakis]

Landed now.