RFR: 7903606: Move layout and function descriptor generation closer to code builders

Jorn Vernee jvernee at openjdk.org
Mon Dec 11 17:53:47 UTC 2023


On Mon, 11 Dec 2023 14:38:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves calls to Type/Declaration.layoutFor/descriptorFor as close as possible to the leaf code builders. The reason for this change is to prepare the jextract code to generate layouts and descrptor strings directly from jextract types, so that we can retain as much information from the original clang cursor/types as possible when generating layouts.
>> 
>> In order to get there, I had to add a lot of type predicates in the Utils class (perhaps some of these methods can be moved later directly in TypeImpl).
>> 
>> And, perhaps the biggest change, is that previously we used layout presence/absence in `UnsupportedFilter` to make decision as to whether skip a certain declaration. For this reason, `UnsupportedFilter` (esp. its type visitor) has been enhanced to detect cases where layout generation would fail, but in a way that does not require us to generate layouts just to answer a question of "is this type supported?".
>
> test/testng/org/openjdk/jextract/test/toolprovider/Test7903257/TestDocComments.java line 72:
> 
>> 70:             "typedef unsigned long long size_t;",
>> 71:             "typedef int INT_32;",
>> 72:             "typedef int* INT_PTR;"));
> 
> opaque structs are now skipped, so there's no interface for them

Shouldn't we still have a primitive typedef? i.e.:


public static final AddressLayout OPAQUE_PTR = Foo_h.C_POINTER;

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

PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422872507


More information about the jextract-dev mailing list