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

[Jorn Vernee]

 > 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/1bcc22e4/attachment-0001.htm>