New lint: repr(packed) without ABI qualification

[Manishearth]

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 {
 ...
}

[GnomedDev]

Even as someone who predominantely uses repr(packed) for memory usage optimisation, this sounds good.