dart:ffi platform-dependent struct layout

[dcharkes]

On different platforms structs have different layouts.

We can reproduce the struct layout algorithm (field sizes + alignment + padding) for platforms.

So that dart:ffi users do not have to write the following.

@ffi.struct({
  'x64 && linux': { // Layout on 64-bit Linux
    'x': ffi.Field(ffi.Double, 0),
    'y': ffi.Field(ffi.Double, 8),
    'next': ffi.Field(ffi.Double, 16)
  },
  'arm && ios': {  // Layout on 32-bit iOS
    'x': ffi.Field(ffi.Float, 4),
    'y': ffi.Field(ffi.Float, 8),
    'next': ffi.Field(ffi.Pointer, 0)
  },
})
class Coord extends ffi.Pointer<Coord> {
  double x;
  double y;
  Coord next;
}

However, in some cases ifdefs might be used to differentiate between platforms. Either users need to be able to specify various layouts, or we need to invoke the C compiler to learn about the struct layouts.

[dcharkes]

Structs with native integers, floats, and pointers are supported on all platforms already. We already have issues open for extending our support to nested structs, inline arrays, and unions. That leaves ifdef-based platform differences:

However, in some cases ifdefs might be used to differentiate between platforms. Either users need to be able to specify various layouts, or we need to invoke the C compiler to learn about the struct layouts.

The current workaround is to define different structs for different platforms, duplicate all the signatures that use these structs, and branch on platform at runtime.

We could try to make this more ergonomic by somehow unifying the different structs into one nominal struct on the Dart-side as described above, but that would considerably complicate passing structs by value in AOT. The Dart VM needs to know the exact layout of the struct at compile time. See discussion in #37842.

So for now, we will stick with the workaround.

cc @mkustermann

[dcharkes]

We will stick with not unifying it into one nominal struct.

• We support all normal struct layout rules (when not using ifdefs in the API).
• Supporting ifdefs would break IDE support, does some struct field exist yes or no? The analyzer does not know what is the target architecture.

The current workaround is to define different structs for different platforms, duplicate all the signatures that use these structs, and branch on platform at runtime.

We can make this more ergonomic by generating this code from the header file #35843.