<div dir="ltr"><div>
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.

</div><div><br></div><div>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).</div><div><br></div><div>I can update my branch with those changes and make an mr out of it if you'd like to use it as reference?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023 at 3:06 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com">jorn.vernee@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
This exception comes from the following section in <br>
TypeMaker::makeTypeInternal:"<br>
<br>
             case Unexposed:<br>
             case Elaborated:<br>
                 org.openjdk.jextract.clang.Type canonical = <br>
t.canonicalType();<br>
                 if (canonical.equalType(t)) {<br>
                     throw new TypeException("Unknown type with same <br>
canonical type: " + t.spelling());<br>
                 }<br>
                 return makeType(canonical);<br>
<br>
I think in this case we're looking at an 'Unexposed' type, which means <br>
that libclang (the C interface of clang) does not support this type [1]. <br>
Looking at the implementation of `GetTypeKind` in libclang [2], it <br>
delegates to `GetBuiltinTypeKind` [3] for builtin types, and this <br>
doesn't have a case for BFloat16, so instead it returns <br>
`CXType_Unexposed`. i.e. this seems to be an issue that needs to be <br>
fixed in libclang itself. There might be other changes that are needed <br>
to fully support this type, but I can't say off the top of my head.<br>
<br>
As a workaround, we might be able to specifically detect __bf16 based on <br>
its name/spelling, and then return an instance of Type.Primitive from <br>
TypeMaker::makeTypeInternal, that is later filtered out in <br>
`UnsupportedLayouts`. That would allow jextract to continue and generate <br>
something, but wouldn't work for cases where the __bf16 type is actually <br>
required since we would just omit any function/variable that used this <br>
type in its declaration.<br>
<br>
Jorn<br>
<br>
[1]: <br>
<a href="https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#gaad39de597b13a18882c21860f92b095a" rel="noreferrer" target="_blank">https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#gaad39de597b13a18882c21860f92b095a</a><br>
[2]: <br>
<a href="https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L94" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L94</a><br>
[3]: <br>
<a href="https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L29" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L29</a><br>
<br>
On 16/10/2023 20:15, Clayton Walker wrote:<br>
> Hello,<br>
><br>
> I've been working on creating a set of bindings against sdl2, and have <br>
> encountered the following issue:<br>
><br>
> Unknown type with same canonical type: __bf16<br>
><br>
> I wasn't sure what needed to be fixed, perhaps a missing declaration <br>
> or mapping in jextract, but after a bit of digging I tried adding the <br>
> clang BFloat16 data type but had no luck. <br>
> <a href="https://github.com/openjdk/jextract/compare/jdk21...Sineaggi:jextract:jdk-21-bf16" rel="noreferrer" target="_blank">https://github.com/openjdk/jextract/compare/jdk21...Sineaggi:jextract:jdk-21-bf16</a><br>
><br>
</blockquote></div>