Description
In general, rustc lints are held to a standard of "low false positives". Sometimes they may be opinionated (e.g. all the style lints), but they should generally at least be correct about what they are linting on. Unfortunately, the improper_ctypes lint is a grab-bag of opinions, but few of them necessarily reflect the actuality of what safe FFI looks like, partly because Rust's in-compiler understanding of C ABIs is actually fairly lacking. They are over-conservative approximations, which must often be responded to with liberal usage of allow(improper_ctypes).
In other words, it's a clippy lint. Probably multiple (it's already split into improper_ctypes_definitions, for instance).
This is not a new concern, considering:
- Dubious
improper_ctypesfiring on recursive non-local containment? #116831 improper_ctypeslint triggers on valid#[repr(transparent)]types #115457improper_ctypesfails to trigger on invalidrepr(transparent)types #116959- PhantomData<T> doesn't trigger improper_ctypes_definitions lint #94000
improper_ctypeslint should cover "C" abi function pointer types. #95683- future-incompat: use of SIMD types aren't gated properly #87438
- improper_ctypes should not suggest reprs that lead to errors #60757
I'm not the only one who has suggested extensively refactoring it:
Perhaps the more niche cases that it warns on should be moved to clippy and allowed to bake for... a while. This, admittedly, would be the first case that I know of for casting a lint down instead of lifting it up, but it may be justified.