The equality checks for Repr to effectively check ReprStyle didn't make
much sense -- it would result in Repr comparisons failing if ReprType
was set. This becomes important when we add alignment information to
Repr.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

While #[repr(packed)] matches the rest of the currently-implemented
reprs, #[repr(align(...))] adds another level of nesting and so it's
necessary to handle arguments for nested #[repr(...)]s. However,
arguments are only permitted for #[repr(align(...))] and any further
nesting is ignored as before.

It should be noted that #[repr(packed(...))] is also valid in Rust, but
due to some complications with translating it to C, it is currently
unsupported.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

As with #[must_use], this new support requires users to specify what
annotations they would like to apply when an alignment-related repr is
encountered. However, unlike #[must_use] all compilers appear to use the
same attributes to indicate layout settings so there is just a single
configuration for this new feature in a separate [layout] TOML table.

In order to facilitate the fact that #[repr(align(...))] takes an
argument which will likely need to be included in the final annotation,
the user must specify a function-like macro which takes the alignment
value as an argument.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Users configure the annotations for this feature using the same [layout]
settings as for structures (because -- unlike #[must_use] -- all
well-known compilers use the same annotations for all types).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

If the user has not specified a corresponding annotation for types that
carry #[repr(packed)] or #[repr(align(...))] we must not generate the
layout because it can cause interoperability issues (and possible memory
unsafety) between C and Rust code.

This unfortunately required some less-than-pretty plumbing changes so
that the load phase of the parser has access to the complete Config
object (luckily this does make the overall code look a bit cleaner
IMHO). The individual IR loaders only get their corresponding structs,
to avoid introducing confusing semantics.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

The tests are very straightforward, and effecitvely are just ensuring
that the formatting works correctly and is included in all of the
important cases.

It's also very important to ensure we do not generate laid-out structs
for layouts which we cannot reasonably represent in C (such as in cases
where we weren't told what annotation to use for packed and
specifically-aligned structures). Thus, add some tests to verify that
this is the case.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>