[foreign-jextract] RFR: 8240300: jextract produces non compilable code with repeated declarations

[Maurizio Cimadamore]

On Mon, 2 Mar 2020 19:24:14 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Filtering repeated global variables and functions in code generator (added necessary hashCode, equals for decls, types)
>
> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TypeImpl.java line 271:
> 
>> 270:                     argtypes.equals(function.argtypes) &&
>> 271:                     restype.equals(function.restype);
>> 272:         }
> 
> Function with typedef and raw type will not be equal?
> 
> typedef int* intptr;
> void intConsumer(int *ptr);
> void intConsumer(intptr);

Ok, this is maybe something worth considering - should equals for type redefinition be extended/relaxed to cover the following the cases?
A == typedef A B 
typedef A B == A
I don't think the code in this patch is *wrong* - and I can see pros and cons (and use cases) for both approaches.

I guess one thing we should evaluate is whether clients which use equality e.g. for purposes similar to how equality is used in this patch (e.g. come up with a cache of types which have same properties) will benefit more from a 'smart' equality or not.

Now, in our case, since basic jextract normalizes all type references to follow typedefs, it just happens that we really care about deep type equality where typedefs have been replaced. But smarter code generators which preserve the 'shape' of the original code (e.g. which spin synthetic interface for typedeffed types), might not consider `typedef A B` and `A` as the same thing.

So, again, like in the case for declaration, I believe that, perhaps the safest move is to do what Sundar is doing here - and build every other kind of smarter comparison on top (and jextract would need such a smarter comparison too).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/37