improper_ctypes lint allows all "Option-like" enums, but we only guarantee this specifically for Option

[RalfJung]

Ever since its introduction, the FFI safety lint has accepted MyOption<Box<T>> as FFI safe even if MyOption is not the "official" Option type from libcore. This was originally done because "being sound but slightly incomplete is acceptable". However, it doesn't quite reflect today's approaches any more, and IMO the lint should be adjusted to match the documented guarantees -- which AFAIK only cover specifically Option, and not all "Option-like" types.

Cc @rust-lang/opsem @workingjubilee @Noratrieb

[workingjubilee]

@RalfJung Frankly, the improper_ctypes lint has so many false positives that I cannot honestly countenance adding more BS to it.

[workingjubilee]

It also cannot be modified because even the smallest change, to not eagerly warn on things that are not a problem, is deferred to a T-lang decision, e.g. #116863

[workingjubilee]

I already actively recommend to people to simply silence the lint, in direct communication, when it proves to be the slightest problem. I will feel forced to more proactively recommend silencing the lint if this is done, in venues like "the documentation for FFI libraries used by many corporations".

Yyyes, it's kind of silly that we don't guarantee this quality for non-Option, non-Result enums that nonetheless "look like" Option and Result. But I already have enough trouble encouraging people to use the compiler correctly when things "don't cause problems in practice" (read: their code is actively UB but it hasn't visibly miscompiled yet). In this case, we actually do know it doesn't cause problems in practice.

If we fix literally every other problem with improper_ctypes first?

...well, that'll be a while, but then I'd endorse such an action: https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3A%22L-improper_ctypes%22

Though, I'd probably file an RFC to extend the Option and Result guarantees first to all enums that we will give similar representations. Because I feel like we do want to guarantee this for them, and the main reason we haven't is that we aren't completely sure we want to close that door yet, or do something like give Option and Result their own repr annotation that would guarantee this representation.

[RalfJung]

I don't think we need t-lang to make the lint fire on more cases. And it's not a false positive - those layouts are literally not guaranteed. Enum layout is very underspecified and adjusting the lint should come *after* specifying it more, if that is something someone is interested in pursuing.

[lolbinarycat]

I was under the impression that the null pointer optimization was guaranteed for all "Option-like" enums, but i can't find a normative reference for that

closest i can find is this:
https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums

[RalfJung]

Cc @chorman0773

[chorman0773]

It is, in fact, only guaranteed for Option<T> and now Result<T,E>/Result<S,T> for a 1zst E or S.

[RalfJung]

The FCP here seems to have established a guarantee for all Option-like types?