jextract error: Crossing storage unit boundaries

[Maurizio Cimadamore]

I'll take a closer look. We did some changes in this area, to fix
issues associated to bitfields parsing.

The new code now works generally better, but is also stricter in
rejecting headers which break some of the invariants that are relied
upon (unfortunately, the underlying issue here is that libclang is not
100% transparent when it comes to bitfield allocation).

My suspicion here is that there is some "pack" pragma involved, and a
bitfield which crosses one storage boundary into the next, which is not
supported.

My feeling is that, in these corner cases, we should try to keep going
with code generation, and issue a warning, rather than completely blow
up code generation.

Maurizio

On Mon, 2021-02-22 at 12:54 +0000, Duncan Gittins wrote:
> I've missed some recent messages so sorry if this repeats anything
> that 
> has been reported before or already captured in bug db for ongoing
> fix.
> 
> I just pulled latest panama-foreign and rebuilt, the jextract no
> longer 
> works on Windows:
> 
>      set "WINKIT=c:\Program Files (x86)\Windows 
> Kits\10\Include\10.0.18362.0"
>      jextract -source  -lole32   -t duncan.winh -d gen.java --filter 
> combaseapi.h  -I "%WINKIT%\um" "%WINKIT%\um\shlobj_core.h"
> 
> => fails with message: Crossing storage unit boundaries
> 
> Kind regards
> 
> Duncan
>