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?

[chorman0773]

Interesting. It's not been documented outside of the UCG from what I can tell.

[chorman0773]

In relation to the lint itself, I would agree with Jubilee also - even if this is a false negative, I'd very much prefer we fix the inordinate false positives before addressing false negatives. The lint is IMO useless as is, because of its false positives, so making it lint on more things (even things it should be linting on) isn't going to make it any more useful (can't catch a bug if the lint has been blanket allowed due to FP).

[workingjubilee]

Noting in passing this T-lang decision that specifically permits rustc_nonnull_optimization_guaranteed to include -1, for extra fun: #97122

[RalfJung]

Interesting -- this was never put into any docs it seems, only the lint "knows" about this.

[the8472]

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

That didn't update the layout chapter in the rust reference though. In fact the reference still doesn't mention niches at all, even the ones guaranteed in core.

If a guarantee is made in an FCP and it's nowhere to be read, does that constitute a spec?

🌲🔉

[RalfJung]

@rust-lang/lang since this is a t-lang FCP (from five years ago), we'd be interested in your take on this. :)

Does the behavior of the improper_ctypes lint, where all option-like enums are accepted for the null pointer layout guarantee, constitute a stable guarantee that we should properly document somewhere, or not?

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in the triage meeting today and agreed that we meant what was in the FCP in #60300, that we're still OK with it, that it is (and has been) a language guarantee, and that we're OK with documenting it.

Note that this guarantee will be subsumed by the one that we're making now via FCP in:

• Finish stabilization of result_ffi_guarantees #130628

[RalfJung]

Okay, I think that means we can close this issue -- thanks for clarifying!