cargo metadata panics when you have a dependency to a bin crate

[koute]

Steps to reproduce:

cargo new --bin foo
cargo new --lib bar
cd bar
echo 'foo = { path = "../foo" }' >> Cargo.toml
cargo metadata --format-version=1

Output:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:463
   5: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:350
   6: rust_begin_unwind
             at libstd/panicking.rs:328
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:71
   8: core::panicking::panic
             at libcore/panicking.rs:51
   9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  10: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  11: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  12: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  13: cargo::ops::cargo_output_metadata::output_metadata
  14: cargo::commands::metadata::exec
  15: cargo::cli::main
  16: cargo::main
  17: std::rt::lang_start::{{closure}}
  18: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  19: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  20: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:374
             at libstd/rt.rs:58
  21: main
  22: __libc_start_main
  23: <unknown>

This is a regression - on stable it works and returns valid metadata.

cargo 1.27.0-nightly (9e53ac6 2018-05-07)
rustc 1.27.0-nightly (2f2a11dfc 2018-05-16)

[hdhoang]

Thanks for narrowing this down to [bin]! I think it's caused by this lib_target.unwrap()
a312c55#diff-0ce94b4ba0dbe6aae098fb9298088b4fR141

cc @matklad could you take a look? pietroalbini/crater-tree generates dummy crates to test compilation, and those dummies might depends on binary-only crates.

[alexcrichton]

I believe this should be fixed in #5558

[hdhoang]

This is no longer an issue with cargo c3b09c968 2018-05-27.