warn less about non-exhaustive in ffi

[workingjubilee]

Bindgen allows generating #[non_exhaustive] #[repr(u32)] enums. This results in nonintuitive nonlocal improper_ctypes warnings, even when the types are otherwise perfectly valid in C.

Adjust for actual tooling expectations by avoiding warning on simple enums with only unit variants.

Closes #116831

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

The docs don't make explicit that the ABI matches C's - https://doc.rust-lang.org/reference/type-layout.html#primitive-representation-of-field-less-enums - my sense is that's probably just an oversight?

But as-is it's not clear to me that this is accurate.

[workingjubilee]

typedef enum Name: uint8_t {
    /* fields */
} Name;

is legal C code as-of C23 and must, by brute force of logic, match

#[repr(u8)]
enum Name {
    /* fields */
}

or fail to compile, according to my understanding. (There simply isn't any other valid representation for the two types in either language's rules, if the Rust variants are data-free: they must match.)

[workingjubilee]

I am happy to revise the wording but

• it would be inconsistent with improper_ctypes as-is to warn on u32 in FFI
• the inadequacy of the docs is a preexisting issue it seems
• if I had my druthers I would yeet the entire idea of linting on another crate's types in a crate that isn't the declaring crate from the lint, because it seems absurd, especially when in an extern "C" block that is only declaring a binding against C functions, not declaring a new Rust function (thus the bound function implicitly exists anyway), and this is very much the most-lamented lint in terms of false positives.

[workingjubilee]

I suppose some tests might depend on not having their imports formatted, but this is silly...

[petrochenkov]

When I started reading #116831 my first reaction was "if NodeTag is so special, then it's fine to use allow", but the problem is that you cannot actually apply allow to the single location where it would be most appropriate - enum NodeTag definition.

From the issue it looks like what you want to express is "this enum is non_exhaustive, but I guarantee that no future variant additions will change its ABI, so it's fine to use it in C interfaces and improper_ctypes should not be reported".

Maybe non_exhaustive can be enhanced with some markers describing what we promise not to add, and it would be useful in other situations too, not just in improper_ctypes.
In the meantime the lint could be relaxed.

[petrochenkov]

Warning on #[repr(C)] #[non_exhaustive] was an explicit lang team decision, so I'll send this back to lang team for reconsidering.

[workingjubilee]

When I started reading #116831 my first reaction was "if NodeTag is so special, then it's fine to use allow", but the problem is that you cannot actually apply allow to the single location where it would be most appropriate - enum NodeTag definition.

Correct, if the... approximately entire linting system was reworked, as I understand it, I guess the allow-site could be in the upstream crate?

[petrochenkov]

Well, not allow specifically, something else.
allow is supposed to be placed on the location where something suspicious happens, e.g. a FFI-unsafe type is used in FFI (i.e. fn rdb_read_page in the linked issue).
What we want here is to mark NodeTag as FFI-safe, so it's never suspicious when used in any location.

[workingjubilee]

Right, an arbitrary #[no_really_let_me_promise_a_semistable_abi_yet_nonexhaustive_for_reasons_that_are_really_long_to_explain] technically also works. That solution does not "spark joy", I think, but I can accept it.

[bors]

☔ The latest upstream changes (presumably #124558) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

uhhhh
r? lang