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

[Maurizio Cimadamore]

Looks good - what about calling canonicalType on function args/return 
type also?

Maurizio

On 08/04/2019 13:33, Sundararajan Athijegannathan wrote:
> Updated: https://cr.openjdk.java.net/~sundar/8222025/webrev.01/
>
> * Separate tree phase for builtin types handler
> * TypeDictionary was missing path null check and builtin header file
> * canonicalType() call was missing in Utils.java (for element type of 
> an array)
>
> -Sundar
>
> On 08/04/19, 3:12 PM, Maurizio Cimadamore wrote:
>>
>> On 06/04/2019 04:12, Sundararajan Athijegannathan wrote:
>>> You're right. This fix addresses only typedefs that too that only 
>>> builtin struct/union types only (for now).  This seems to cover 
>>> issues faced with compilation of generated sources. We could walk 
>>> through every type usage in all Trees. Should we/I do that?
>>
>> Maybe as a followup change. The fix is good as is, but let's also try 
>> to fix the more general problem of a jextract run referring to 
>> symbols that aren't there.
>>
>> Maurizio
>>
>>>
>>> Thanks,
>>> -Sundar
>>>
>>> On 06/04/19, 1:49 AM, 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