[foreign] RFR 8220063: Generate LayouType constants as part of jextract output

[Maurizio Cimadamore]

On 05/03/2019 16:16, Jorn Vernee wrote:
> Maurizio Cimadamore schreef op 2019-03-05 17:06:
>> On top of my head, this looks something more for the Ext code factory
>> than for the main one.
>
> But the Ext code factory is for generating the static forwarder. I 
> added it to AsmCodeFactory since the changes affect the classes in the 
> regular (non-"_h") classes.

Good point - doing this kind of things in code factory EXT might be 
tricky - you might want to sync up with Sundar who's looking at how to 
group enum constants in interfaces in the EXT backend:

https://bugs.openjdk.java.net/browse/JDK-8219821


>
> If you think this feels more like an extension, maybe we should try to 
> figure out some extension/plugin framework first, and then implement 
> this feature on top of that (would be a good test case).
>
>> Also, not clear about the changes in LayoutType.ofFunction... there's
>> no inference going on whatsoever, in fact your patch does this
>>
>> +        return LayoutTypeImpl.ofCallback(Address.ofFunction(64,
>> Util.functionof(funcIntf)), References.ofFunction, funcIntf);
>>
>> Yes, we discussed about changing @NativeCallback while back, but I'm
>> not 100% sure that's the direction we should go, and I'd like not to
>> couple things to it.
>
> Instead of the Address layout being passed in, the Function layout is 
> extracted from the @NativeCallback annotation. That's what I mean by 
> "infer that from the @NativeCallback".

My gripe here is: where is the 'size' of the address coming from? I see 
an hardwired '64' here?

Maurizio

>
> I'm not sure what you mean about changing @NativeCallback? This change 
> relies on the current implementation.
>
> Jorn
>
>> Maurizio
>> On 05/03/2019 15:41, Jorn Vernee wrote:
>>
>>> Hi,
>>>
>>> I'd like to contribute a patch which let's jextract generate
>>> LayoutType constants in typedef annotation classes, and struct
>>> classes for the underlying type. The LayoutType constant has the
>>> name of the typedef or struct with an "_t" suffix.
>>>
>>> This is useful because;
>>>
>>> 1.) No need to manually declare a static final LayoutType if you
>>> don't want to call LayoutType.ofStruct(...) everywhere.
>>>
>>> 2.) If an API uses a type in it's documentation/tutorials, but that
>>> type comes from a typedef, in the generated Jextract bindings you
>>> will just find the typedef annotation with that name. But, if we add
>>> a LayoutType constant to the typedef annotation class, the user has
>>> an easy way to find the underlying type as well. (Very useful with
>>> APIs that use typedefs for pretty much anything. Like the Windows
>>> API).
>>>
>>> I might be a little biased towards this, but I've found that
>>> declaring static final LayoutType constants is a must have in
>>> non-trivial projects. Both to reduce verbosity and to show the name
>>> of the API type in the code, not just the name of the underlying
>>> type. e.g. `scope.allocate(MyType_t)` vs.
>>> `scope.allocate(DOUBLE.array(2))`.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220063
>>> Webrev:
>>>
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8220063/webrev.00/
>>>
>>>
>>> I did 3 other things to implement this:
>>>
>>> 1.) Drop Address parameter of LayoutType.ofFunction, since we can
>>> just infer that from the @NativeCallback annotation instead.
>>> 2.) Fixed issue where a typedef of a function type was not
>>> generating an @NativeCallback class.
>>> 3.) Sharpened typing in TypeDictionary and JType w.r.t.
>>> JType.FunctionalInterfaceType.
>>>
>>> Thanks,
>>> Jorn