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

[Jorn Vernee]

On Mon, 11 Dec 2023 14:31:49 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?".

src/main/java/org/openjdk/jextract/impl/StructBuilder.java line 167:

> 165:         appendIndentedLines(STR."""
> 166:             public static \{type.getSimpleName()} \{javaName}$get(MemorySegment \{seg}) {
> 167:                 return \{seg}.get(\{layoutString(1, layout)}, \{offset});

So, It seems that using the layout string directly here is fine since we only reference primitives?

Also, this (and the `set` method) don't need indentation. It results in this:


    public static int x$get(MemorySegment seg) {
        return seg.get(    JAVA_INT, 8);
    }

src/main/java/org/openjdk/jextract/impl/StructBuilder.java line 188:

> 186:         appendIndentedLines(STR."""
> 187:             public static MemorySegment \{javaName}$slice(MemorySegment \{seg}) {
> 188:                 return \{seg}.asSlice(\{offset}, \{size});

I'm not so sure about embedding hard-coded offset and size literals into the generated code. Since, it is not clear what the number represents/where it comes from. This seems to clash with the goal of having the generated code be copy-pastable/understandable.

I think if we go the route of dropping var handle-based accessors in favor of offset-based ones, we should instead generate `static final` offset and size constant fields, and then reference those here.

src/main/java/org/openjdk/jextract/impl/Utils.java line 119:

> 117:             default -> false;
> 118:         };
> 119:     }

This method is only used by the other `isEnum`, and that one is unused (only called recursively). Coverage report also shows the code as dead.

src/main/java/org/openjdk/jextract/impl/Utils.java line 162:

> 160:             case Type.Declared declared when declared.tree().kind() == Declaration.Scoped.Kind.ENUM ->
> 161:                 isPrimitive(((Declaration.Constant)declared.tree().members().get(0)).type());
> 162:             case Type.Delegated delegated -> isPrimitive(delegated.type());

Not sure this is correct for pointers?

src/main/java/org/openjdk/jextract/impl/Utils.java line 170:

> 168:     static Function getAsFunctionPointer(Type type) {
> 169:         return switch (type) {
> 170:             case Type.Delegated delegated -> getAsFunctionPointer(delegated.type());

Same here I think. e.g. not sure this is correct for pointers to function pointers (which are not function pointers themselves)

test/testng/org/openjdk/jextract/test/toolprovider/unsupported/TestUnsupportedTypes.java line 68:

> 66:             {"accepts_undefined_func",           REASON_UNSUPPORTED_TYPE},
> 67:             {"GLOBAL_UNDECLARED",                REASON_UNSUPPORTED_TYPE},
> 68:             {"undefined_typedef",                REASON_UNSUPPORTED_TYPE},

Please remove the `GLOBAL_HAS_UNSUPPORTED` code from the accompanying .h file as well.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422813773
PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422818657
PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422856284
PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422859057
PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422863315
PR Review Comment: https://git.openjdk.org/jextract/pull/156#discussion_r1422868397