jextract fails to parse stdatomic.h

[Maurizio Cimadamore]

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.RecordLayoutComputer.checkSize(RecordLayoutComputer.java:198)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.StructLayoutComputer.finishRecord(StructLayoutComputer.java:142)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.compute(RecordLayoutComputer.java:114)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.computeInternal(RecordLayoutComputer.java:89)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.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.lambda$parse$2(Parser.java:86)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$CursorChildren$Context.visit(Cursor.java:223)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$CursorChildren.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$CursorChildren.forEach(Cursor.java:254)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor.forEach(Cursor.java:194)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.parse(Parser.java:64)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.parse(JextractTool.java:116)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.run(JextractTool.java:466)
> 	at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.main(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
>