[foreign-jextract] RFR: 8260602: jextract generates redundant functional interafces

Athijegannathan Sundararajan sundar at openjdk.java.net
Fri Jan 29 07:52:48 UTC 2021


On Thu, 28 Jan 2021 18:56:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There seems to be an issue in how jextract handles function pointer typedef.
> 
> Currently, these typedefs are handled in two places:
> 
> * OutputFactory::visitVar
> * OutputFactory::visitFunction
> 
> That is, if a variable (struct field or global), or a function parameter is seen to have a typedef of a function pointer, jextract will generate a functional interface _exactly at that point_ where the variable is found. This might be inside a struct.
> 
> Now, what we really want is slightly different: the functional interface for a function pointer typedef should really be generated in the toplevel interface hierarchy; any other reference to it (from struct fields, or function parameters, or globals) should _not_ result in additional functional interface declaration.
> 
> In other words, in this example [1]:
> 
>     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;
> 
> There should be (in the user perspective) only _one_ functional interface, and its name should just be `callback_t`.
> 
> The fix is to make OutputFactory::getAsFunctionPointer non-transparent w.r.t. typedefs - that is, if a typedef is found, that method should just return null (so that the enclosing code will skip functional interface generation). To counter balance that, we need to add logic for functional interface declaration inside OutputFactory::visitTypedef.
> 
> I did not add any new test, since it turns out we already had a test for this (LibTest8258605Test) whose code was referring to the same typedef-ed function pointer using two names - this fix rectifies that behavior, and the test is now updated.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011948.html

Marked as reviewed by sundar (Committer).

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

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


More information about the panama-dev mailing list