[foreign] RFR: 8223489: _Atomic types can cause StackOverflowError

[Maurizio Cimadamore]

I see what you are doing here. I believe there's a cleaner way to get 
there, which is what we've done to process macros.

That is, when you see a cursor with:

_Atomic("....")

extract the innards of that cursor, and create a new temporary 
compilation unit for that one, as we do for macros. I think most of the 
logic we use there should be applicable in this case (only the snippet 
to be generated for the speculative compilation would be different). 
And, probably, if we go down that path we could refactor the code a bit 
so that the functionalities used for the 'speculative' clang evaluation 
can be shared across macro/atomic support.

Maurizio

On 14/05/2019 02:58, Henry Jen wrote:
> Hi,
>
> Please review a webrev[1] that detects an atomic type to get the correct layout for the type.
>
> A proper solution would be have libclang expose the atomic types, so we don’t need to add the ugly hacks in Java to find the type. A patch is submitted[2] to clang project and hopefully this can be fixed in future release.
>
> Before that happens, we have our java clang binding trying do that work by:
> - Put together a temporary header file with C11 types to parse, so we can get this builtin-types.
> - During the cursor-traversing, we will add in extra types declared in the header files
> - For an atomic type, we use the type string to get the underlying type.
>
> Note that an atomic type is always a builtin type without valid declaration cursor, so we cannot get the translation unit the type actually defined in, so we are doing a global search. Since jextract will only created one translation unit, the hack should work just fine without much pollution.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/panama/8223489/0/webrev/
> [2] https://reviews.llvm.org/D61716