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

[Jorn Vernee]

> but that there are other cases where you might want to have access to 
> LayoutTypes in a more direct fashion.

The particular use case where I needed something like this, was where I 
had a pointer to a loaded .dll/.exe image, and had to cast it to 
different 'header' structs to get at the data. And also where I'd get a 
relative virtual address from the base of the image, which then had to 
be casted into the right type. So, another use case is casting.

e.g.

```
     public static PEImage loadInternal(Pointer<HINSTANCE__> lib) {
         Pointer<Byte> image = cast(BYTE_t, lib);

         _IMAGE_DOS_HEADER dos_header = cast(IMAGE_DOS_HEADER_t, 
image).get();
         if (dos_header.e_magic$get() != IMAGE_DOS_SIGNATURE)
             throw new IllegalArgumentException("No DOS signature");

         _IMAGE_NT_HEADERS64 header = cast(IMAGE_NT_HEADERS64_t, 
image.offset(dos_header.e_lfanew$get())).get();
         if (header.Signature$get() != IMAGE_NT_SIGNATURE)
             throw new IllegalArgumentException("No NT signature");

         return new PEImage(image, header);
     }
```

Jorn

Maurizio Cimadamore schreef op 2019-03-05 17:15:
> That said, if we really pull more on this string, what you have
> proposed (which is a fine idea) feels like a step in between these two
> points:
> 
> 1) raw:
> 
> scope.allocateStruct(LayoutType.ofStruct(MyStruct.class));
> 
> (which btw, can become just allocateStruct(MyStruct.class))
> 
> 2) full decorated
> 
> MyStruct s = MyStruct.allocate(scope);
> 
> Now, this is especially true for allocation, I can but that there are
> other cases where you might want to have access to LayoutTypes in a
> more direct fashion.
> 
> But again, this feels like an 'ext' feature; if we do that, I suggest
> we use the TYPE name for the static LayoutType holder, similarly to
> what has been done in Java core classes.
> 
> e.g.
> 
> MyStruct.TYPE.pointer();
> 
> But overall, i can't help but feeling that this is a civilization kind
> of use case; not sure whether hardwiring some behavior in jextract is
> the right way to go here.
> 
> Maurizio
> On 05/03/2019 16:06, Maurizio Cimadamore wrote:
> 
>> 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