New correctness lint: uninhabited_reference

[pitaj]

What it does

This lint will trigger whenever using a reference to an uninhabited type, such as !, Infallible, or Void.

This should apply recursively, like when a struct has an uninhabited field. But care should be taken that this applies to an enum type only when all variants are uninhabited, such that &Result<(), !> does not trigger the lint.

Advantage

Creating a reference to an uninhabited type is a footgun at best and UB at worst, and can only be achieved via unsafe code. Essentially, it's never correct to have a reference to an uninhabited type.

Drawbacks

No response

Example

// This function shouldn't be possible to call
fn impossible(_thing: &Infallible) {}

fn foo(thing: &Infallible) {
    // But we call it here because somehow we have a reference
    impossible(thing);
}

Should be denied wholesale.

[Nadrieril]

Creating a reference to an uninhabited type is UB and can only be achieved via unsafe code.

This is not fully true: it is not decided yet whether that is UB, see rust-lang/unsafe-code-guidelines#413. It is however unsafe to do so; in other words, a safe value of type &Void cannot exist. Dereferencing such a value is instant UB.

If I may add, the motivation for the OP lint is the unfortunate case of using *const Void to denote an extern type. Having a *const Void in safe code is fine. If a bindings library ever exposed a &Void to safe code however, that would be terribly unsound.

[RalfJung]

To quote Jules Bertholet who put this very well on Zulip:

As soon as you have an &Uninhabited, you have broken a safety invariant; usually the size of the space between safety and validity invariant is treated as a private implementation detail