Panic parsing serde_derive with parse_deps = true

[ralfbiedert]

Hi,

When trying to generate bindings for this code:

use serde::{Deserialize, Serialize};

#[repr(C)]
#[derive(Serialize, Deserialize)]
pub struct Vec3f32 {
    x: f32,
    y: f32,
    z: f32,
}

#[no_mangle]
pub extern "C" fn f(x: *const Vec3f32) -> f32 {
    x.x
}

with a Cargo.toml containing

[dependencies]
serde = { version = "1.0", features = ["derive"] }

and a cbindgen.toml:

language = "C"

[parse]
parse_deps = true

The following panic is produced

WARN: Parsing crate `serde_derive`: can't find lib.rs with `cargo metadata`.
thread 'main' panicked at 'IntoIter is not generic', /Users/rb/.cargo/registry/src/github.com-1ecc6299db9ec823/cbindgen-0.12.1/src/bindgen/ir/opaque.rs:107:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: std::panicking::begin_panic_fmt
   8: <cbindgen::bindgen::ir::opaque::OpaqueItem as cbindgen::bindgen::ir::item::Item>::instantiate_monomorph
   9: cbindgen::bindgen::ir::ty::Type::add_monomorphs
  10: cbindgen::bindgen::library::Library::generate
  11: cbindgen::bindgen::builder::Builder::generate
  12: cbindgen::main
  13: std::rt::lang_start::{{closure}}
  14: std::panicking::try::do_call
  15: __rust_maybe_catch_panic
  16: std::rt::lang_start_internal
  17: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Link to project that should reproduce the issue. I am running cbindgen 0.12.1 and rustc 1.40.0 (73528e339 2019-12-16).

... hah, and I just realized I filed a very similar issue #195 that was related to #203, however, both of which are closed now. Since this time the problem is related to specifying parse_deps = true I'm not sure if they are after all related or not.

[emilio]

I couldn't reproduce the issue with cbindgen src/lib.rs --config cbindgen.toml, checking out that branch. It generates the expected code... How are you invoking cbindgen?

[ralfbiedert]

On Windows machine now, original report was from Mac, but running cbindgen src/lib.rs --config cbindgen.toml works here as well, but just cbindgen --config cbindgen.toml produces the panic again.

[emilio]

Ah, ok, I can repro that, thank you :)

[lu-zero]

If you want a reduced testcase I tripped in the same problem with:

type Complex = num_complex::Complex<f32>;

pub const CONST: i32 = 42;