Promote uninhabited_static lint to a hard error

[WaffleLapkin]

The lint was introduced as a FCW in #78324 and landed in rust 1.49.0 (5 years ago); see also #74840. I think we can promote this to a hard error ^^'

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[WaffleLapkin]

T-lang nomination

This PR promotes the uninhabited_static lint to a hard error. This lint detects statics with types which are uninhibited, e.g.:

enum Void {}
unsafe extern {
    static EXTERN: Void;
}

The lint was reported as FCW for 5 years now.

[fmease]

This obviously doesn't account for visibility meaning if upstream makes a public type with private fields uninhabited it could break downstream.

Is that already considered to be a breaking change due to other features? I see a bunch of uses of is_uninhabited in the compiler, so maybe?

Counterexamples: Exhaustiveness checking accounts for visibility at module granularity even, #[repr(transparent)] no longer permits external types with private fields (well, it's still a future-incompat deny-by-default lint, repr_transparent_non_zst_fields).

Edit: This concern probably doesn't really matter actually, it's super theoretical. It's more important that we reject the bad statics.

[WaffleLapkin]

I thought about it a bit and I think for this lint specifically this is fine.

a static implies the existence of the value, so there is either

• Some library that provides a value of such type (extern static)
• Some (accessible) function that returns a value of such type (normal static)

In both cases making the value uncostructable would already be a breaking change.

---

Another way to look at this: having a static of an uninhabited type is unsound and leads to UB on basically any use of such static. We shouldn't compile such programs, period.

[fmease]

We shouldn't compile such programs, period.

I do agree.

having a static of an uninhabited type is unsound and leads to UB on basically any use of such static

Re. supposed unsoundness tho, is that really the case? Merely defining such a static isn't insta-UB or is it? And since extern statics are unsafe to reference, no language invariant is broken in safe code, so it's not unsound; sure it is UB but that would be the user's fault.

[WaffleLapkin]

Fair enough, it slipped from my mind that those accesses are unsafe.

[nnethercote]

r=me for the code changes, just waiting on lang approval.

View changes since this review

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[traviscross]

@bors2 try

[scottmcm]

I was debating how necessary it would be to have this be a hard error, since arguably it's "just" someone lying in their unsafe extern { ... }. But especially given that unsafe extern { safe static FOO: !; } exists now it feels particularly silly since it's clearly not safe, it make sense to treat this kinda like a "well it's a hard error to do UB that we detect".

And most importantly, in any place where this fires it seems clearly like using MaybeUninit<UninhabitedThing> as the type is the only thing that could possibly be meant anyway, so they should just write that.

(The meeting brought up that we should probably crater check this just in case, but I expect that to go through fine.)

[traviscross]

It's worth noting here that, though this has been an FCW for a long time, it's only set to warn and is not set to report in deps. If we were to decide to not make this a hard error immediately, it'd seem that would be the natural next step. In the meeting, we talked about how perhaps if there is no observed breakage in crater that we might be OK with going to a hard error directly regardless.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 9b8307b (9b8307bcb9d1de8ffc7e1c81c48efffdb24ee840, parent: 568b11762723b001bfa693d0f21c5dad01d4e813)

[traviscross]

@craterbot check

[craterbot]

👌 Experiment pr-149518 created and queued.
🤖 Automatically detected try build 9b8307b
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more