[External] : Re: Jextract failure on llvm 17.0.1 with sdl

[Clayton Walker]

> Thanks, that could be useful for reference.

https://github.com/openjdk/jextract/commit/0fc1334d442d9f9eeec1ffc92a9e5e2c2c184c2e

On Tue, Oct 17, 2023 at 1:34 AM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> > I can update my branch with those changes and make an mr out of it if
> you'd like to use it as reference?
>
> Thanks, that could be useful for reference.
>
> I think we might want to change the error handling strategy of unexposed
> types in general, and instead filter them out, rather than crashing with an
> exception.
>
> Jorn
> On 17/10/2023 02:15, Clayton Walker wrote:
>
> Thanks for the additional details, other than working around it I was
> pretty lost when I found out that its kind was (as you mentioned)
> unexposed.
>
> To get around that locally (pretty sure nothing in SDL requires __bf16) I
> ended up adding a case to canonical.equalType(t) where if
> t.spelling().equals("__bf16") I return
> Type.primitive(Primitive.Kind.BFloat16). (Which itself is added to the
> Type.Primitive.Kind class as an unsupported layout size 2).
>
> I can update my branch with those changes and make an mr out of it if
> you'd like to use it as reference?
>
> On Mon, Oct 16, 2023 at 3:06 PM Jorn Vernee <jorn.vernee at oracle.com>
> wrote:
>
>> Hi,
>>
>> This exception comes from the following section in
>> TypeMaker::makeTypeInternal:"
>>
>>              case Unexposed:
>>              case Elaborated:
>>                  org.openjdk.jextract.clang.Type canonical =
>> t.canonicalType();
>>                  if (canonical.equalType(t)) {
>>                      throw new TypeException("Unknown type with same
>> canonical type: " + t.spelling());
>>                  }
>>                  return makeType(canonical);
>>
>> I think in this case we're looking at an 'Unexposed' type, which means
>> that libclang (the C interface of clang) does not support this type [1].
>> Looking at the implementation of `GetTypeKind` in libclang [2], it
>> delegates to `GetBuiltinTypeKind` [3] for builtin types, and this
>> doesn't have a case for BFloat16, so instead it returns
>> `CXType_Unexposed`. i.e. this seems to be an issue that needs to be
>> fixed in libclang itself. There might be other changes that are needed
>> to fully support this type, but I can't say off the top of my head.
>>
>> As a workaround, we might be able to specifically detect __bf16 based on
>> its name/spelling, and then return an instance of Type.Primitive from
>> TypeMaker::makeTypeInternal, that is later filtered out in
>> `UnsupportedLayouts`. That would allow jextract to continue and generate
>> something, but wouldn't work for cases where the __bf16 type is actually
>> required since we would just omit any function/variable that used this
>> type in its declaration.
>>
>> Jorn
>>
>> [1]:
>>
>> https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#gaad39de597b13a18882c21860f92b095a
>> <https://urldefense.com/v3/__https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html*gaad39de597b13a18882c21860f92b095a__;Iw!!ACWV5N9M2RV99hQ!OOM7TsQZCXwAs_t2bGO_j68nqkZ-6mf1jTtdoxwayDzY2dFg2gJ5RQV7cmEiUkgWRrIpkaeduhjWHliDRqKUJf-tYP9L$>
>> [2]:
>>
>> https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L94
>> <https://urldefense.com/v3/__https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp*L94__;Iw!!ACWV5N9M2RV99hQ!OOM7TsQZCXwAs_t2bGO_j68nqkZ-6mf1jTtdoxwayDzY2dFg2gJ5RQV7cmEiUkgWRrIpkaeduhjWHliDRqKUJc5TGq3w$>
>> [3]:
>>
>> https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L29
>> <https://urldefense.com/v3/__https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp*L29__;Iw!!ACWV5N9M2RV99hQ!OOM7TsQZCXwAs_t2bGO_j68nqkZ-6mf1jTtdoxwayDzY2dFg2gJ5RQV7cmEiUkgWRrIpkaeduhjWHliDRqKUJdqgfirJ$>
>>
>> On 16/10/2023 20:15, Clayton Walker wrote:
>> > Hello,
>> >
>> > I've been working on creating a set of bindings against sdl2, and have
>> > encountered the following issue:
>> >
>> > Unknown type with same canonical type: __bf16
>> >
>> > I wasn't sure what needed to be fixed, perhaps a missing declaration
>> > or mapping in jextract, but after a bit of digging I tried adding the
>> > clang BFloat16 data type but had no luck.
>> >
>> https://github.com/openjdk/jextract/compare/jdk21...Sineaggi:jextract:jdk-21-bf16
>> <https://urldefense.com/v3/__https://github.com/openjdk/jextract/compare/jdk21...Sineaggi:jextract:jdk-21-bf16__;!!ACWV5N9M2RV99hQ!OOM7TsQZCXwAs_t2bGO_j68nqkZ-6mf1jTtdoxwayDzY2dFg2gJ5RQV7cmEiUkgWRrIpkaeduhjWHliDRqKUJQ47_1rf$>
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20231017/6e9830cf/attachment-0001.htm>