Description
(Elaborating on #66220 (comment))
I think that the current state of improper_ctypes
is difficult to maintain and extend -- especially once we add more lints that are similar but distinct -- because it's a big pile of mud that interleaving several different concerns: UCG-ish questions about ABI and layout guarantees, plus value judgements about how these interact with "proper" FFI, plus diagnostics code and suggestions. I imagine (but have not worked out the details) that we could improve this by separating this code into two "layers":
- A module (some queries?) answering clean-cut spec questions such as: does this type have a defined memory layout? Defined ABI? If not, why not? etc.
- Several lints that use the facts from that module as basis for emitting warnings, depending on what the lint is targeted at.
I think such an organization would make it clearer what are the language-level guarantees are (including making it easier to audit and evolve) vs what's just a choice or limitation of some lint. More importantly, it would also enable us to implement (without lots of duplication and without making the visitor even more of a big ball of mud) a broader variety of lints that need similar information. For example:
- linting transmutes of types with unspecified layout ([WIP] Impl a more strict transmute check #51294, Warn and eventually forbid transmute::<T, U> for T or U with unspecified (Rust) layout #50842)
- separate lints for "ABI is FFI-safe" vs "C code could actually work with this type" independent of
extern
imports vs definitions - lints for type punning via unions
(theconst
alternative totransmute
) - a more opinionated version of
improper_ctypes
that e.g. prohibits references (due to their aliasing implications which are rarely appropriate in FFI)