Description
What it does
This lints against #[repr(packed)] without specifying repr(C, packed) or repr(Rust, packed).
Advantage
repr(packed) by default implies repr(Rust, packed). However, this representation is not stable, which makes it less useful: the bulk of repr(packed) use cases are for interfacing with certain binary formats (where it needs to be repr(C, packed)) and for zero-copy deserialization (which needs to be stable). The best use case for repr(Rust, packed) is for reducing binary size
In fact, it is my experience that people tend to assume repr(packed) means "the same as C __attribute__((packed))", since it doesn't actually make much sense to introduce a new packed repr.
This means some of the ecosystem is using #[repr(packed)] to mean #[repr(C, packed)], and getting broken by changes like rust-lang/rust#125360.
It seems like good practice for everyone to explicitly specify if they want C or Rust when asking for repr(packed). Probably a "suspicious" category lint: it's not guaranteed broken, but it's likely to be, and it's also just misleading.
Drawbacks
No response
Example
#[repr(packed)]
pub struct Foo {
...
}Could be written as:
#[repr(C, packed)]
pub struct Foo {
...
}