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

[Maurizio Cimadamore]

On top of my head, this looks something more for the Ext code factory 
than for the main one.

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.

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