You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 callfnimpossible(_thing:&Infallible){}fnfoo(thing:&Infallible){// But we call it here because somehow we have a referenceimpossible(thing);}
Should be denied wholesale.
The text was updated successfully, but these errors were encountered:
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.
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
What it does
This lint will trigger whenever using a reference to an uninhabited type, such as
!
,Infallible
, orVoid
.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
Should be denied wholesale.
The text was updated successfully, but these errors were encountered: