[foreign-jextract] Duplicated interface declarations when using typedefs for function pointers

[Filip Krakowski]

Hi,

it's really great how outstandingly fast bugs are fixed! Thank you very 
much for this :)

Filip

On 1/29/21 1:41 PM, Maurizio Cimadamore wrote:
> On Thu, 2021-01-28 at 18:57 +0000, Maurizio Cimadamore wrote:
>> Filed this:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8260602
>>
>> Thanks for the report!
>>
>> Maurizio
> This has been fixed now.
>
> We realized that some of the jextract samples in our document [1] were
> also referring to suboptimal functional interface names. We will fix
> the document shortly.
>
> Thanks again.
>
> Maurizio
>
> [1] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md
>>
>> On Thu, 2021-01-28 at 17:57 +0000, Maurizio Cimadamore wrote:
>>> This seems odd. But I guess I can see why jextract ends up doing
>>> that.
>>>
>>> I think what jextract *should* do is to reuse the interface for
>>> `callback_t` whenever possible (which should be declared at the
>>> toplevel).
>>>
>>> In other words, it seems like jextract is re-generating a new
>>> interface
>>> every time it encounters a reference to a function pointer typedef,
>>> which seems a bug.
>>>
>>> Maurizio
>>>
>>>
>>>
>>> On Thu, 2021-01-28 at 18:48 +0100, Filip Krakowski wrote:
>>>> Hi,
>>>>
>>>> I just noticed that jextract generates duplicate code
>>>> (interfaces)
>>>> for
>>>> function pointers within each struct instead at the top-level.
>>>> Each interface's name seems to have a suffix based on the
>>>> occurrence
>>>> of
>>>> the declaration in the source file.
>>>>
>>>>      typedef void (*callback_t)(void *arg);
>>>>
>>>>      typedef struct first_handler {
>>>>           callback_t cb;
>>>>      } first_handler_t;
>>>>
>>>>      typedef struct second_handler {
>>>>           callback_t cb;
>>>>      } second_handler_t;
>>>>
>>>> This code generates the following java source code.
>>>>
>>>>      @C("struct first_handler")public static class first_handler {
>>>>      ...
>>>>           public static interface cb {
>>>>
>>>>                   void apply(jdk.incubator.foreign.MemoryAddress
>>>> x0);
>>>>
>>>>                   public static  @C("callback_t") MemorySegment
>>>>      allocate(cb fi) {
>>>>                       return RuntimeHelper.upcallStub(cb.class,
>>>> fi,
>>>>      ucx_h_constants_0.cb$FUNC(),
>>>>      "(Ljdk/incubator/foreign/MemoryAddress;)V");
>>>>                   }
>>>>
>>>>                   public static  @C("callback_t") MemorySegment
>>>>      allocate(cb fi, NativeScope scope) {
>>>>                       return allocate(fi).handoff(scope);
>>>>                   }
>>>>               }
>>>>      ...
>>>>      }
>>>>
>>>>      @C("struct second_handler")public static class second_handler
>>>> {
>>>>      ...
>>>>           public static interface cb$0 {
>>>>
>>>>                   void apply(jdk.incubator.foreign.MemoryAddress
>>>> x0);
>>>>
>>>>                   public static  @C("callback_t") MemorySegment
>>>>      allocate(cb$0 fi) {
>>>>                       return RuntimeHelper.upcallStub(cb$0.class,
>>>> fi,
>>>>      ucx_h_constants_0.cb$0$FUNC(),
>>>>      "(Ljdk/incubator/foreign/MemoryAddress;)V");
>>>>                   }
>>>>
>>>>                   public static  @C("callback_t") MemorySegment
>>>>      allocate(cb$0 fi, NativeScope scope) {
>>>>                       return allocate(fi).handoff(scope);
>>>>                   }
>>>>               }
>>>>      ...
>>>>      }
>>>>
>>>>   From my point of view both interfaces are identical. Is there a
>>>> reason
>>>> for placing them inside the struct class?
>>>>
>>>>
>>>> Best regards
>>>> Filip
>>>>
>>>>