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

[Athijegannathan Sundararajan]

On Mon, 2 Mar 2020 21:56:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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).

Yes.  Not sure if we can handle it without underlying clang Type objects around. I'll see if simple cases can be handled at least.

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

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