jextract error: Crossing storage unit boundaries

[Maurizio Cimadamore]

This has been fixed now. I've tested it on windows.h which now extracts
fine.

Apologizes again for the inconvenience.

Cheers
Maurizio

On Mon, 2021-02-22 at 19:12 +0000, Maurizio Cimadamore wrote:
> We are working on a fix - I agree that throwing is too harsh - the
> fix will report warning if the bitfield cannot be parsed.
> 
> Maurizio
> 
> On Mon, 2021-02-22 at 18:21 +0000, Duncan Gittins wrote:
> Hi Maurizio
> 
> Thanks. Maybe jextract needs a "-warn" mode, for the occasions where
> jextract is used on headers that cannot be fixed. I haven't work out
> which layout is the trouble-maker in my specific case but fortunately
> I don't seem to depend on it as my app works fine after I commented
> out these lines:
> 
> StructLayoutComputer.java:
> // throw new IllegalStateException("Crossing storage unit
> boundaries");
> LayoutUtils.java:
> // throw new IllegalStateException("Cannot infer container layout");
> 
> Duncan
> 
> On Mon, 22 Feb 2021 at 13:15, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>
> > wrote:
> 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
> > 
> 
> On Mon, 22 Feb 2021 at 13:15, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>
> > wrote:
> 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
> >