POINTER_ALIGNMENT not applied to Rust structs about wdkmetadata

[kennykerr]

Doesn't look like there's any metadata for that - not sure what that would be. I'll pass this question on to the win32metadata repo for discussion.

[mikebattista]

Related to microsoft/win32metadata#1044 where ClangSharp doesn't scrape DECLSPEC_ALIGN.

@tannergooding any updates on this issue?

[tannergooding]

Haven't had a chance to dig into it yet.

This is also a particularly troublesome case since its not packing, but rather individual field adjustments which can't be represented by many languages/runtimes and a case where the layout will differ between 32-bit and 64-bit, so its not something that can necessarily be picked up with a single traversal.

-- Even with this metadata, I'm not sure Rust has an attribute to do this layout itself. It has repr(C) and it has packed(x) and align(x), but those are all for structs, not fields. I think at best it would need to have a nested transparent struct with its own align modifier (differing for 32-bit vs 64-bit).

[tannergooding]

-- If someone else wants to give it a go, contributions are welcome and the relevant attributes should be available off the AST nodes already.

[ChrisDenton]

Even with this metadata, I'm not sure Rust has an attribute to do this layout itself. It has repr(C) and it has packed(x) and align(x), but those are all for structs, not fields. I think at best it would need to have a nested transparent struct with its own align modifier (differing for 32-bit vs 64-bit).

I don't think there's any problem with that, so long as the metadata is there. A PointerAlignment<T> struct makes sense. There are other places we do shenanigans to make things work (e.g. Rust doesn't have inline unions). An alternative would be manually adding padding which is a bit blah.

[tannergooding]

I don't think there's any problem with that, so long as the metadata is there

Sure, just it needs to be clarified where it is relevant for ABI purposes/etc.

T and S<T> (given struct S<T> { T value; }) are different from the ABI perspective. This is why rust has the "transparent struct" attribute -- this is particularly relevant for COM/instance methods on Windows where struct returns are treated differently from primitive returns

Similarly, struct S { int32_t x; int64_t y; } and struct S { int32_t x; int32_t padding; int64_t y; } are different and may be handled differently by some platforms/ABIs/classifiers, so manually declaring padding is not "safe" -- many ABI classification systems ignore padding bits, but do not ignore explicitly declared fields. Thus this can change whether its classified as HFA/HVA or how many registers it can be split across.

An anonymous struct/union is likewise explicitly a different struct/union, just one where language syntax allows direct access and thus struct S { int32_t x; struct { int32_t x; int32_t y; } is different from struct S { int32_t x; int32_t y; int32_t z; } from the ABI/layout perspective -- this becomes particularly relevant in cases such as struct S { struct { int64_t x; int32_t y; } int32_t z; } where the fact that it is a nested anonymous struct means the size is (8 + 4 + 4 padding) + (4 + 4 padding) (and therefore size=24, not size=16). This also often impacts inheritance in C++ where the first field is explicitly Base not the same fields
from Base repeated inline.

There are even platforms where the signedness of the type is relevant for ABI purposes and thus int32_t and uint32_t are different, thus causing incorrect results if you declare your interop signature taking i32 where the actual signature took u32 or vice versa.