thread 'main' panicked at 'Not able to resolve vector element?: Continue', bindgen/ir/ty.rs:1149:22

[glandium]

Clang trunk recently moved some declarations around, which ended up exposing them in what Firefox processes for bindings, and this breaks bindgen:

Input C/C++ Header

typedef _Float16 __v8hf __attribute__((__vector_size__(16), __aligned__(16)));
typedef _Float16 __m128h __attribute__((__vector_size__(16), __aligned__(16)));
typedef _Float16 __m128h_u __attribute__((__vector_size__(16), __aligned__(1)));

typedef __bf16 __v8bf __attribute__((__vector_size__(16), __aligned__(16)));
typedef __bf16 __m128bh __attribute__((__vector_size__(16), __aligned__(16)));

Bindgen Invocation

bindgen::Builder::default()
    .header("input.h")
    .generate()
    .unwrap()

Actual Results

thread 'main' panicked at 'Not able to resolve vector element?: Continue', bindgen/ir/ty.rs:1149:22
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/result.rs:1814:5
   3: core::result::Result<T,E>::expect
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/result.rs:1064:23
   4: bindgen::ir::ty::Type::from_clang_ty
             at ./bindgen/ir/ty.rs:1143:33
   5: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::from_ty_with_id
             at ./bindgen/ir/item.rs:1668:22
   6: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::from_ty
             at ./bindgen/ir/item.rs:1565:9
   7: bindgen::ir::context::BindgenContext::resolve_typerefs
             at ./bindgen/ir/context.rs:908:36
   8: bindgen::ir::context::BindgenContext::gen
             at ./bindgen/ir/context.rs:1144:9
   9: bindgen::codegen::codegen
             at ./bindgen/codegen/mod.rs:4462:5
  10: bindgen::Bindings::generate
             at ./bindgen/./lib.rs:2540:43
  11: bindgen::Builder::generate
             at ./bindgen/./lib.rs:1580:9
  12: testcase::main
             at ./testcase/src/main.rs:5:5
  13: core::ops::function::FnOnce::call_once
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Insert panic message and backtrace (set the `RUST_BACKTRACE=1` env var) here.

[glandium]

Ping @emilio

[emilio]

Hmm, that crashes clang-14 here:

clang -isystem /usr/lib/clang/14.0.6/include -isystem /usr/local/include -isystem /usr/include t.h                                                                                                                              [NORMAL] 
t.h:1:9: error: _Float16 is not supported on this target
typedef _Float16 __v8hf __attribute__((__vector_size__(16), __aligned__(16)));
        ^
t.h:2:9: error: _Float16 is not supported on this target
typedef _Float16 __m128h __attribute__((__vector_size__(16), __aligned__(16)));
        ^
t.h:3:9: error: _Float16 is not supported on this target
typedef _Float16 __m128h_u __attribute__((__vector_size__(16), __aligned__(1)));
        ^
t.h:5:9: error: __bf16 is not supported on this target
typedef __bf16 __v8bf __attribute__((__vector_size__(16), __aligned__(16)));
        ^
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: clang -isystem /usr/lib/clang/14.0.6/include -isystem /usr/local/include -isystem /usr/include t.h
1.	t.h:5:76: current parser token ';'
 #0 0x00007f5860ed545a (/usr/lib/libLLVM-14.so+0xcd545a)
 #1 0x00007f5860ed2aef llvm::sys::RunSignalHandlers() (/usr/lib/libLLVM-14.so+0xcd2aef)
 #2 0x00007f5860dbfb59 (/usr/lib/libLLVM-14.so+0xbbfb59)
 #3 0x00007f585fc51a00 (/usr/lib/libc.so.6+0x38a00)
 #4 0x00007f5868882f11 clang::Sema::BuildVectorType(clang::QualType, clang::Expr*, clang::SourceLocation) (/usr/lib/libclang-cpp.so.14+0x1482f11)
 #5 0x00007f586888b847 (/usr/lib/libclang-cpp.so.14+0x148b847)
 #6 0x00007f5868893c2e (/usr/lib/libclang-cpp.so.14+0x1493c2e)
 #7 0x00007f58698b0c29 (/usr/lib/libclang-cpp.so.14+0x24b0c29)
 #8 0x00007f58683e5f2b clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef<clang::TemplateParameterList*>) (/usr/lib/libclang-cpp.so.14+0xfe5f2b)
 #9 0x00007f58683e69a9 clang::Sema::ActOnDeclarator(clang::Scope*, clang::Declarator&) (/usr/lib/libclang-cpp.so.14+0xfe69a9)
#10 0x00007f5867bef029 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/usr/lib/libclang-cpp.so.14+0x7ef029)
#11 0x00007f5867c0ef0f clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/lib/libclang-cpp.so.14+0x80ef0f)
#12 0x00007f5867c137f9 clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*, clang::SourceLocation*) (/usr/lib/libclang-cpp.so.14+0x8137f9)
#13 0x00007f5867c13c88 clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributesWithRange&, clang::SourceLocation*) (/usr/lib/libclang-cpp.so.14+0x813c88)
#14 0x00007f5867c8f20c clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/usr/lib/libclang-cpp.so.14+0x88f20c)
#15 0x00007f5867c8f9f6 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) (/usr/lib/libclang-cpp.so.14+0x88f9f6)
#16 0x00007f5867bd9f18 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/libclang-cpp.so.14+0x7d9f18)
#17 0x00007f58691b3919 clang::FrontendAction::Execute() (/usr/lib/libclang-cpp.so.14+0x1db3919)
#18 0x00007f5869152e07 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/libclang-cpp.so.14+0x1d52e07)
#19 0x00007f586920a7ca clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/libclang-cpp.so.14+0x1e0a7ca)
#20 0x00005584424556f1 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang-14+0x176f1)
#21 0x0000558442457337 (/usr/bin/clang-14+0x19337)
#22 0x00007f5868eaa499 (/usr/lib/libclang-cpp.so.14+0x1aaa499)
#23 0x00007f5860dbfc27 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/usr/lib/libLLVM-14.so+0xbbfc27)
#24 0x00007f5868eaffff (/usr/lib/libclang-cpp.so.14+0x1aaffff)
#25 0x00007f5868ec5763 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/usr/lib/libclang-cpp.so.14+0x1ac5763)
#26 0x00007f5868ec5b39 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/usr/lib/libclang-cpp.so.14+0x1ac5b39)
#27 0x00007f5868ecde72 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/usr/lib/libclang-cpp.so.14+0x1acde72)
#28 0x000055844244c46a main (/usr/bin/clang-14+0xe46a)
#29 0x00007f585fc3c290 (/usr/lib/libc.so.6+0x23290)
#30 0x00007f585fc3c34a __libc_start_main (/usr/lib/libc.so.6+0x2334a)
#31 0x000055844244d655 _start (/usr/bin/clang-14+0xf655)
clang-14: error: clang frontend command failed with exit code 136 (use -v to see invocation)
clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-14: note: diagnostic msg: 
********************

But I can repro on clang trunk.

[ShayBox]

Sorry for bumping this old issue but I'm not knowledgeable enough to fill out a new issue template. I ran into this issue trying to compile ovr_overlay which uses autocxx-bindgen, the issue occurs using any version of LLVM/Clang prior to v17 pre but the library hasn't changed since my last successful build with LLVM/Clang 15 on GitHub Actions and 16 on Windows...

I don't know if this repo is the right place for autocxx-bindgen but the fork of this repo that it's based on has issues disabled... I tried using an old ovr_overlay commit, old autocxx-bindgen versions, older minor/patch versions of v15/16 but nothing works except v17 pre for some reason, nothing has changed.

EDIT: I'm not the library creator (I'm just trying to use it in my project) and don't know much about the subject, I tried contacting the dev for support but they either can't replicate it or can't figure it out either.

[pvdrz]

Hi @ShayBox, we don't have any association with the autocxx-bindgen so we cannot help you there. If you are able to give us a reproducible example of this issue with one of the bindgen releases we'd be happy to help.

[ShayBox]

Hmm I figured this was the repo for autocxx-bindgen because the source repository is a fork of this one with issues disabled, but this strange clang/bindgen/autocxx breaking behavior somewhere in the toolchain is being looked into here now.