bindgen fails with panic: "C'mon: Continue"

[jsgf]

I assume this is one of the template issues @emilio has mentioned before, but here it is for completeness.

Input:

namespace
{
  namespace
  {
    template < template < typename > class Atom > struct SequentialThreadId
    {
      Atom < unsigned >prevId;
    };
}}

Command: bindgen lib.i --enable-cxx-namespaces -- -x c++ -std=gnu++14

Fails with:

thread 'main' panicked at 'C'mon: Continue', rust/1.14/src/rust/src/libcore/result.rs:837
stack backtrace:
   1:     0x7f4cb52330ca - std::sys::imp::backtrace::tracing::imp::write::h917062bce4ff48c3
                        at rust/1.14/src/rust/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x7f4cb523932f - std::panicking::default_hook::{{closure}}::h0bacac31b5ed1870
                        at rust/1.14/src/rust/src/libstd/panicking.rs:247
   3:     0x7f4cb5237626 - std::panicking::default_hook::h5897799da33ece67
                        at rust/1.14/src/rust/src/libstd/panicking.rs:263
   4:     0x7f4cb5237c77 - std::panicking::rust_panic_with_hook::h109e116a3a861224
                        at rust/1.14/src/rust/src/libstd/panicking.rs:451
   5:     0x7f4cb5237b04 - std::panicking::begin_panic::hbb38be1379e09df0
                        at rust/1.14/src/rust/src/libstd/panicking.rs:413
   6:     0x7f4cb5237a29 - std::panicking::begin_panic_fmt::h26713cea9bce3ab0
                        at rust/1.14/src/rust/src/libstd/panicking.rs:397
   7:     0x7f4cb52379b7 - rust_begin_unwind
                        at rust/1.14/src/rust/src/libstd/panicking.rs:373
   8:     0x7f4cb527903d - core::panicking::panic_fmt::hcfbb59eeb7f27f75
                        at rust/1.14/src/rust/src/libcore/panicking.rs:69
   9:     0x7f4cb4f4f999 - core::result::unwrap_failed::h4e4433ae10a88bed
  10:     0x7f4cb4f8bc8f - libbindgen::ir::ty::Type::from_clang_ty::h97c6dca021b74c7b
  11:     0x7f4cb4f8a0f6 - libbindgen::ir::ty::Type::from_clang_ty::h97c6dca021b74c7b
  12:     0x7f4cb4f869e6 - <libbindgen::ir::item::Item as libbindgen::parse::ClangItemParser>::from_ty_with_id::h21c03d7c8b580fdd
  13:     0x7f4cb4f79bef - libbindgen::ir::context::BindgenContext::resolve_typerefs::hc4ae2c59af527bef
  14:     0x7f4cb4f8eed2 - libbindgen::Bindings::generate::h0f3a09f9547090eb
  15:     0x7f4cb4f8e336 - libbindgen::Builder::generate::haa90db6fe5ae5d21
  16:     0x7f4cb4f3df4f - bindgen::main::h9b246eb7746cc895
  17:     0x7f4cb524221a - __rust_maybe_catch_panic
                        at rust/1.14/src/rust/src/libpanic_unwind/lib.rs:97
  18:     0x7f4cb5238695 - std::rt::lang_start::hd661476ce2fc2931
                        at rust/1.14/src/rust/src/libstd/panicking.rs:332
                        at rust/1.14/src/rust/src/libstd/panic.rs:351
                        at rust/1.14/src/rust/src/libstd/rt.rs:57
  19:     0x7f4cb42fdb14 - __libc_start_main
  20:     0x7f4cb4f1f614 - <unknown>

[emilio]

Ok, so I know why this one happens, but I don't know what are we supposed to generate there? I can't think of a valid way to translate that in rust off-hand, given rust doesn't accept template parameters on template parameters?

I guess we can skip it, but then something else will come up that uses that id.

I think either skipping, or marking the type as opaque automatically is the best we can do here?

[jsgf]

I still get a failure if I set --blacklist-type=.* or --opaque-type=.*, so it looks like its failing before it ever gets around to deciding what its going to output.

I don't think the type in question is relevant to the interface I'm working with, so "auto-opaque" would be fine, assuming it needs to be generated at all.

[emilio]

Yeah, this is a failure during parsing. We try to have a consistent view of the world before generating code...

Oh well, C++, you win this time.

I can't work on it right now (about to go to an exam, and today will be busy in general), but I guess propagating the error up the chain (from the is_fully_specialized_template_check up) would be enough to make the error disappear. May be more tricky than that because of other callers, but as a quick hack if it's not generated it may work.

[jsgf]

I guess the ideal is that bindgen should be able to cope with any syntactically and type-correct C++ input, even if it has to emit placeholders for parts it can't represent in Rust.

In this case, I guess the template <template <typename> Atom> is a HKT?

[fitzgen]

In this case, I guess the template <template Atom> is a HKT?

Yep. Maybe we can revisit once ATCs happen...

Or maybe we can try to properly track everything in parsing and ir and then emit opaque types in codegen.

[emilio]

On Wed, Jan 11, 2017 at 01:24:31AM -0800, Nick Fitzgerald wrote:

Or maybe we can try to properly track everything in parsing and ir and then emit opaque types in codegen.

I think that may not be really doable, since even with less esoteric usage of template parameters libclang starts falling short already.

We could make this fallible (unlike now) and return an invalid item that won't be generated.

Sounds easier said than done though.

[fitzgen]

Sounds easier said than done though.

Should be easier with #544 which introduces a TypeKind::Opaque so that making opaque blobs is a bit easier than it was before.

[fitzgen]

New stack trace after #544:

thread 'main' panicked at 'Should have found the template definition one way or another', /checkout/src/libcore/option.rs:785
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: core::option::expect_failed
             at /checkout/src/libcore/option.rs:785
   1: <core::option::Option<T>>::expect
             at /checkout/src/libcore/option.rs:293
   2: bindgen::ir::template::TemplateInstantiation::from_ty
             at ./src/ir/template.rs:103
   3: bindgen::ir::ty::Type::from_clang_ty
             at ./src/ir/ty.rs:992
   4: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::from_ty_with_id
             at ./src/ir/item.rs:1174
   5: bindgen::ir::item::visit_child
             at ./src/ir/item.rs:877
   6: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::from_ty_with_id::{{closure}}
             at ./src/ir/item.rs:1204
   7: bindgen::clang::visit_children
             at ./src/clang.rs:608
   8: _ZN5clang8cxcursor13CursorVisitor5VisitE8CXCursorb
   9: _ZN5clang8cxcursor13CursorVisitor17VisitTemplateNameENS_12TemplateNameENS_14SourceLocationE
  10: _ZN5clang8cxcursor13CursorVisitor34VisitTemplateSpecializationTypeLocENS_29TemplateSpecializationTypeLocE
  11: _ZN5clang14TypeLocVisitorINS_8cxcursor13CursorVisitorEbE5VisitENS_7TypeLocE
  12: _ZN5clang8cxcursor13CursorVisitor19VisitDeclaratorDeclEPNS_14DeclaratorDeclE
  13: _ZN5clang8cxcursor13CursorVisitor14VisitFieldDeclEPNS_9FieldDeclE
  14: _ZN5clang11declvisitor4BaseINS0_8make_ptrENS_8cxcursor13CursorVisitorEbE5VisitEPNS_4DeclE
  15: _ZN5clang8cxcursor13CursorVisitor13VisitChildrenE8CXCursor
  16: clang_visitChildren
  17: clang_sys::clang_visitChildren
             at /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-0.14.0/src/link.rs:94
  18: bindgen::clang::Cursor::visit
             at ./src/clang.rs:364
  19: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::from_ty_with_id
             at ./src/ir/item.rs:1203
  20: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::from_ty
             at ./src/ir/item.rs:1087
  21: bindgen::ir::context::BindgenContext::resolve_typerefs
             at ./src/ir/context.rs:426
  22: bindgen::ir::context::BindgenContext::gen
             at ./src/ir/context.rs:572
  23: bindgen::codegen::codegen
             at ./target/debug/build/bindgen-fddff672ca36ebc4/out/codegen.rs:4349
  24: bindgen::Bindings::generate
             at ./src/lib.rs:748
  25: bindgen::Builder::generate
             at ./src/lib.rs:469
  26: bindgen::main::{{closure}}
             at ./src/main.rs:55
  27: std::panicking::try::do_call
             at /checkout/src/libstd/panicking.rs:454
  28: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  29: std::panicking::try
             at /checkout/src/libstd/panicking.rs:433
  30: std::panic::catch_unwind
             at /checkout/src/libstd/panic.rs:361
  31: bindgen::main
             at ./src/main.rs:54

[pvdrz]

I ran this at commit 61636e94 and got:

Warning: can't set `binop_separator = Back`, unstable features are only available in nightly channel.
/* automatically generated by rust-bindgen 0.60.1 */

#[allow(non_snake_case, non_camel_case_types, non_upper_case_globals)]
pub mod root {
    #[allow(unused_imports)]
    use self::super::root;
    pub mod _bindgen_mod_id_1 {
        #[allow(unused_imports)]
        use self::super::super::root;
        pub mod _bindgen_mod_id_2 {
            #[allow(unused_imports)]
            use self::super::super::super::root;
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct SequentialThreadId {
                pub prevId: u8,
            }
        }
    }
}

is that aceptable?

[amanjeev]

I tried this with latest master and I do not have have the warning anymore. @jsgf please let us know if this is resolved or needs work? This helps in triage.

/* automatically generated by rust-bindgen 0.60.1 */

#[allow(non_snake_case, non_camel_case_types, non_upper_case_globals)]
pub mod root {
    #[allow(unused_imports)]
    use self::super::root;
    pub mod _bindgen_mod_id_1 {
        #[allow(unused_imports)]
        use self::super::super::root;
        pub mod _bindgen_mod_id_2 {
            #[allow(unused_imports)]
            use self::super::super::super::root;
            #[repr(C)]
            #[derive(Debug, Copy, Clone)]
            pub struct SequentialThreadId {
                pub prevId: u8,
            }
        }
    }
}