Collapse #[repr(transparent)] types

[Firestar99]

Supersedes #566

[LegNeato]

This looks directionally good to me.

Insole_structural_newtype_field it talks about “one non-ZST field”, but repr(transparent) is more specific...ignored fields must be both size 0 and align 1. Looks like we are only checking is_zst()?

Also a few more projection tests might be good, something like:

#[repr(transparent)]
struct W(Inner);

and then use W through &W, &mut W, raw pointers, arrays/slices, function args/returns, and nested transparent wrappers. Mostly want to make sure that once the wrapper type gets collapsed, accessing .0 still becomes a no-op and we don't accidentally emit an invalid access chain.

Might worth adding a test for an over-aligned ZST too:

#[repr(align(8))]
struct Blah;

#[repr(transparent)]
struct W {
    inner: u32,
    marker: Blah,
}

marker is size 0 but it has alignment 8 so it can affect W’s layout.

Requesting changes, but feel free to put up again if you are merely extracting and don't want to change anything.

[Firestar99]

Rewrote all the tests, seems like all the GEPs are emitted just fine

[LegNeato]

@eddyb please take a look.

[eddyb]

Oh, this is so easy now, thanks to SpirvType not having to match the rustc-side layout (other than having fields at the right offsets).

I've wanted to do this in the past, but the existence of e.g. struct_gep was blocking it (seems like that has been gone since rust-lang/rust@beed25b huh).

My only worry now is whether we have code acting on Ty/layout, and SpirvType, simultaneously, and expecting any connection between the two.

[Firestar99]

Forge-merging since @LegNeato's review is blocking the merge

[nazar-pc]

Interesting, does this suffer from the same issue?:

#[repr(C)]
pub struct X(u32);

If so, then it should probably be treated the same way as #[repr(transparent)], at least for simple cases like this one.

[Firestar99]

I wasn't going to do it with #[repr(C)] cause removing that struct "layer" will influence inline assembly, as GEPs (aka OpAccessChain) need one index less. Though I honestly don't know if there's a situation where this is actually problematic.

[nazar-pc]

I'm sure a general case is more involved, but I'd expect for trivial integers the result should be identical. This PR got me thinking if I'm leaving performance on the table by complicating the code with #[repr(C)] new types.