Lockfile parsing fails with "invalid serialized PackageId for key package.dependencies"

[str4d]

When I try to run cargo authors inside https://github.com/zcash/halo2, I get the following error:

$ git rev-list -n 1 HEAD
ec38a06fbf2d74247363828141a02172b8c7c848
str4d@Charana:~/dev/rust/zcash/halo2 (main) ^_^
$ RUST_BACKTRACE=1 cargo authors
error: failed to parse lock file at: /home/str4d/dev/rust/zcash/halo2/Cargo.lock
caused by: invalid serialized PackageId for key `package.dependencies`
backtrace:    0: failure::backtrace::internal::InternalBacktrace::new
   1: failure::backtrace::Backtrace::new
   2: cargo::ops::lockfile::load_pkg_lockfile
   3: cargo::ops::resolve::resolve_with_registry
   4: cargo::ops::resolve::resolve_ws_with_method
   5: cargo::ops::resolve::resolve_ws_precisely
   6: cargo_authors::real_main
   7: cargo_authors::main
   8: std::sys_common::backtrace::__rust_begin_short_backtrace
   9: std::rt::lang_start::{{closure}}
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:379:40
      std::panicking::try
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:343:19
      std::panic::catch_unwind
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panic.rs:396:14
      std::rt::lang_start_internal
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/rt.rs:51:25
  11: main
  12: __libc_start_main
  13: _start

I installed cargo-authors using Rust 1.50.0.

[str4d]

I get this with other crates too, so my initial guess (before digging in at all) is that this crate doesn't support the v2 lockfile format? rust-lang/cargo#7070

[Henning-K]

Thank you for the bug report and the quick fix. I checked out your branch and everything appears to be in order.