jextract fails to parse stdatomic.h

[Maurizio Cimadamore]

Hi,
A fix for this issue is being worked on here:

https://github.com/openjdk/jextract/pull/132

This will be backported to the 21 branch (and we will respin new
binaries for it).

CheersMaurizio

On Fri, 2023-10-20 at 09:51 -0700, Artem Ananev wrote:
> Hi Maurizio, 
> 
> thank you for quick response.
> 
> Is there a workaround to this issue? Will it be addressed in the
> final version of FFI / jextract?
> 
> From what I saw during debugging, your assumption about the
> underlying problem looks right. In TypeImpl class there is a field
> `layoutMaker`, which implements a type visitor. When this issue with
> atomic_flag happens, this visitor throws an unsupported exception
> from its visitType() method.
> 
> Thanks,
> Artem
> 
> > On Oct 19, 2023, at 5:05 PM, Maurizio Cimadamore <
> > maurizio.cimadamore at oracle.com> wrote:
> > 
> > Hi Artem,
> > thanks for the report. This issue is probably a latent one, which
> > has been made manifest by a recent PR:
> > 
> > https://git.openjdk.org/jextract/pull/121
> > 
> > I believe the underlying cause is that there is some type involved
> > in this declaration is not supported (meaning we can't generate a
> > layout for it). This causes the layout to be dropped from the
> > struct. But now we have a size mismatch, as clang is reporting that
> > the size of the struct is 1 byte, but, since we end up with an
> > empty struct layout, our size is zero.
> > 
> > If I had to guess (given the headers involved), I'd say that the
> > Atomic type kind is not supported by TypeMaker.
> > 
> > Probably related to this old issue:
> > https://mail.openjdk.org/pipermail/panama-dev/2019-May/005387.html
> > 
> > Maurizio
> > 
> > On 20/10/2023 00:42, Artem Ananev wrote:
> > > Hi,
> > > 
> > > I use jextract version "JDK version 21+35-LTS-2513” on a Ubuntu
> > > 22.04.3 box. It fails with the following error:
> > > 
> > > ```
> > > java.lang.AssertionError: Unexpected size for layout []. Found 0
> > > ; expected 1
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo
> > > utComputer.checkSize(RecordLayoutComputer.java:198)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.StructLayo
> > > utComputer.finishRecord(StructLayoutComputer.java:142)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo
> > > utComputer.compute(RecordLayoutComputer.java:114)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo
> > > utComputer.computeInternal(RecordLayoutComputer.java:89)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo
> > > utComputer.compute(RecordLayoutComputer.java:71)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker.
> > > createRecord(TreeMaker.java:205)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker.
> > > createTreeInternal(TreeMaker.java:104)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker.
> > > createTree(TreeMaker.java:93)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.lam
> > > bda$parse$2(Parser.java:86)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$Cu
> > > rsorChildren$Context.visit(Cursor.java:223)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$Cu
> > > rsorChildren.lambda$static$0(Cursor.java:242)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.libclang.
> > > Index_h.clang_visitChildren(Index_h.java:5108)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$Cu
> > > rsorChildren.forEach(Cursor.java:254)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor.fo
> > > rEach(Cursor.java:194)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.par
> > > se(Parser.java:64)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.pa
> > > rse(JextractTool.java:116)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.ru
> > > n(JextractTool.java:466)
> > > 	at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.ma
> > > in(JextractTool.java:174)
> > > Unrecoverable uncaught exception encountered. The VM will now
> > > exit
> > > ```
> > > 
> > > There is no way to understand where exactly it fails, so I
> > > downloaded jextract sources, ran it in debug mode, and found the
> > > error happens when it’s parsing <stdatomic.h>, in particular this
> > > line:
> > > 
> > > ```
> > > typedef struct atomic_flag { atomic_bool _Value; } atomic_flag;
> > > ```
> > > 
> > > If I comment out this line (and all other declarations in the
> > > same header that depend on atomic_flag), jextract no longer
> > > fails. Note that this header is a part of jextract distribution,
> > > it’s in <jextract home>/conf/jextract/stdatomic.h
> > > 
> > > Steps to reproduce:
> > > 
> > > ```
> > > echo '#include <stdatomic.h>' >/tmp/test.h && jextract --source
> > > /tmp/test.h
> > > ```
> > > 
> > > Thanks,
> > > Artem
> > >