repr(align(...)) added or removed on struct, enum, or union

[obi1kenobi]

Breaking because of:
https://jack.wrenn.fyi/blog/semver-snares-alignment/
https://old.reddit.com/r/rust/comments/kr41sq/semver_snares_sizedness_and_size/

Now documented at:
https://doc.rust-lang.org/cargo/reference/semver.html#type-layout

[max-heller]

I'm interested in working on this!

[obi1kenobi]

Awesome! Here are the most-related lints we have right now:

• repr(C) removed from struct: https://github.com/obi1kenobi/cargo-semver-check/blob/main/src/queries/struct_repr_c_removed.ron
• repr(C) removed from enum: https://github.com/obi1kenobi/cargo-semver-check/blob/main/src/queries/enum_repr_c_removed.ron

I put a little syntax explainer in this sibling issue, it covers most of the concepts this lint will need as well so please check it out:
#73 (comment)

Let's focus on writing the query we'll need first, and then we can pretty straightforwardly add the test cases, error messages, etc.

In addition to the information in the link above:

• We'll need a regex filter operator instead of the contains / not_contains filter operators in the repr(C) lints I linked above.
• We'll need to say "none of the current attributes match this regex" instead of "the list doesn't contain this element." This will require the @fold @transform(...) @filter(...) construct ("no such neighbors exist" construct) as in the link above.
• For that construct, we'll need to refer to the attributes as neighboring vertices (attribute edge) of the item, rather than just a list of strings that's a property of the item (attrs property). Check out the schema: https://github.com/obi1kenobi/cargo-semver-check/blob/main/src/rustdoc_schema.graphql

It's totally fine if the new lint runs into bug #104 as well, that's on me for not representing attributes better in the schema. Whenever we fix #104, we can do a pass through all the affected lints as well, and in the meantime we'll just bear with the extra false-negatives. In this project, false negatives are unfortunate, but false positives are deal-breakers.

Ping me with any questions! Happy to hop on a video call if that would make it easier to get started, and I'm also in the rust-lang zulip if you'd prefer more interactive text chat.

I'm also working with a few friends on a WASM-powered web editor for Trustfall queries with all the modern conveniences (autocomplete, syntax highlighting, etc.), stay tuned! 🤞

[CLIDragon]

Hi @obi1kenobi, I've messaged you on Zulip about starting to work on this issue. Documentation is clear (repr-c-add) that adding #[repr(C)] to a default representation structure is a minor change, but it's not clear whether it is breaking to add it to primitive, align, or packed representations. I'm currently working with the assumption that it is not breaking for align and packed based on the wording from the rust reference which implies that C provides orthogonal guarantees to align and packed:

On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.

However, I am unsure about adding C to a primitive representation. Any guidance would be appreciated!

EDIT: Whoops, I just realised I misread the title of the issue 😂 and this post really belongs in #949. Happy to delete/move it if you want to keep this issue clean.

[obi1kenobi]

No worries, it's all good. repr(C) is orthogonal to align/packed/int primitive representation, and adding it is minor in all those cases as well. I don't expect the lint's query will have to special-case any of them at all, but it would still be nice to have test cases for each of them for documentation and "just in case" regression protection purposes.