Panic when running cargo update in a [workspace] only crate with 2 package crate in it's dir

[codyps]

src: https://github.com/jmesmon/ioctl/tree/workspace-cargo-bug

x@y /home/x/g/ioctl % cargo -V
cargo 0.13.0-nightly (afaffa1 2016-09-06)
x@y /home/x/g/ioctl % RUST_BACKTRACE=1 cargo update
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:317
stack backtrace:
   1:     0x5588935680a3 - std::sys::backtrace::tracing::imp::write::h46f28e67d38b4637
   2:     0x55889357150d - std::panicking::default_hook::{{closure}}::h1d3243f546573ff4
   3:     0x55889357079a - std::panicking::default_hook::h96c288d728df3ebf
   4:     0x558893570d98 - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   5:     0x558893570c32 - std::panicking::begin_panic::hfbeda5aad583dc32
   6:     0x558893570b70 - std::panicking::begin_panic_fmt::h4fe9fb9d5109c4bf
   7:     0x558893570af1 - rust_begin_unwind
   8:     0x5588935adc9f - core::panicking::panic_fmt::h4395919ece15c671
   9:     0x5588935adbcb - core::panicking::panic::hc74ff52ed78364e1
  10:     0x5588931b36d3 - cargo::ops::lockfile::write_pkg_lockfile::h162deef0c25d5dc1
  11:     0x558893141d59 - cargo::ops::cargo_generate_lockfile::generate_lockfile::h1961a4fa38b887c3
  12:     0x558893141fc7 - cargo::ops::cargo_generate_lockfile::update_lockfile::h35287c4bedfd66e4
  13:     0x558893075687 - cargo::try_execute::hac87fe5021ec29cd
  14:     0x55889304c135 - cargo::execute::hf5ba8f03b1a33e9a
  15:     0x55889303e164 - cargo::call_main_without_stdin::h12b4266586e2d4eb
  16:     0x55889304a9c4 - cargo::main::ha1e5f2a52416e0a7
  17:     0x558893578fd6 - __rust_maybe_catch_panic
  18:     0x558893570011 - std::rt::lang_start::haaae1186de9de8cb
  19:     0x7f937807f290 - __libc_start_main
  20:     0x558893031328 - <unknown>
x@y /home/x/g/ioctl % git status --ignored
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

        Cargo.toml~
        base/Cargo.toml~
        base/examples/smoke.rs~
        base/src/lib.rs~
        base/src/platform/linux.rs~
        sys/Cargo.toml~
        sys/etc/process_ioctls.py~
        sys/src/lib.rs~
        sys/src/platform/linux.rs~

nothing to commit, working tree clean

[codyps]

Minimal reproduction:

mkdir ws
cd ws
echo '[workspace]' >Cargo.toml
cargo new p1
cargo new p2
cargo update

Probably should complain about current package believes it's in a workspace when it's not again.

[alexcrichton]

I believe that the unwrap is this line, and yeah I think Cargo just needs to yield an error here instead saying you can't generate a lock file for an empty workspace.

[alexcrichton]

Should be an easy bug to tackle though!

[jhbabon]

@alexcrichton I can have a look at this if nobody else is doing it.

[alexcrichton]

@jhbabon all yours! Let me know if you need any pointers.

[jhbabon]

@alexcrichton I was thinking, maybe it is not better to put this in the validate() method of the Workspace struct?

cargo/src/cargo/core/workspace.rs

Line 320 in b931a0f

fn validate(&mut self) -> CargoResult<()> {

[alexcrichton]

Hm yeah, that actually sounds like a much better place to put it!

[jhbabon]

@alexcrichton so I've been investigating a bit more, and I think this error happens with commands like update because these commands never use the method Workspace.current(). This method only works if the current package is not virtual and I think that's our case. We don't want the command update to run on virtual workspaces, just actual packages, right? Or I'm missing something?

If this is the case, maybe we can validate that the workspace it's not virtual during the execution of the update command. This way the command will be consistent with others like build that displays an error like this:

manifest path `[..]` is a virtual manifest, but this command requires running against an actual package in this workspace

[jhbabon]

I came up with this solution, but I don't know if it's the best option: #3092

[jhbabon]

Should we consider to close this after this merge #3092 ?

[alexcrichton]

Indeed, thanks @jhbabon!