[foreign] RFR 8222025: jextract generates reference to underfined type for va_list

[Sundararajan Athijegannathan]

No, in this case, I get the actual definition of the builtin record 
types -- and generate proper interfaces (as nested interfaces of 
clang_support.builtin$ class).

To use resulting the __va_list_tag struct, user would have to fill 
gp_offset, fp_offset, reg_save_area etc. which is not possible (because 
caller frame would be java).
In other words, we add fake Trees with the real clang Cursors with 
actual defs (only path is missing for which we use path of builtin$.h file)

-Sundar

On 06/04/19, 1:51 AM, Maurizio Cimadamore wrote:
> Also, forgot to add, maybe add a test where we show that using the 
> builtin type will lead to an exception?
>
> Maurizio
>
> On 05/04/2019 21:19, Maurizio Cimadamore wrote:
>> Looks a very nice fix! This is also related to the issue that Jorn 
>> was trying to fix while ago re. incomplete array types, so maybe 
>> after this is pushed, we can revisit that topic.
>>
>> One question: this patch attempts to fix missing builtins only in 
>> case they appear in typedefs, right? That is ok for the va_list case, 
>> but I guess it doesn't address the more general problem where 
>> builtins are used directly (I assume not all of them will be 
>> typedef'ed) ? What would be the plan there?
>>
>> Maurizio
>>
>>
>> On 05/04/2019 11:49, Sundararajan Athijegannathan wrote:
>>> Please review.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222025
>>> Webrev: https://cr.openjdk.java.net/~sundar/8222025/webrev.00/
>>>
>>> "builtin" type is detected by source file location having "null" 
>>> path. For each builtin record type, we generate fake Trees and add 
>>> to the list of declarations. A builtin header file ("builtin$.h") is 
>>> used as a target header for such declarations. This ensures that we 
>>> only generate one copy of builitin mappings & all builtin type 
>>> references resolve to those.
>>>
>>> Thanks,
>>> -Sundar