'cargo run' miscounts binaries due to features, can even panic

[BenWiederhake]

Discovered while working indirectly on cargo_run.rs.

Example 1: One binary in the eyes of cargo_run (wrong), but cargo_compile produces no binaries (correct), making cargo_run panic:

// BEGIN Cargo.toml
[package]
name = "foo"
version = "0.1.0"
authors = []

[features]
default = []
phantom = []

[[bin]]
name = "foobar"
path = "src/main.rs"
required-features = ["phantom"]
// END Cargo.toml
// BEGIN src/lib.rs
// END src/lib.rs
// BEGIN src/main.rs
fn main() {
    println!("hello");
}
// END src/main.rs

Behavior:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
thread 'main' panicked at 'assertion failed: `(left == right)` (left: `0`, right: `1`)', /checkout/src/cargo/ops/cargo_run.rs:56
note: Run with `RUST_BACKTRACE=1` for a backtrace.
$ echo $?
101
$

Example 2: Two binaries in the eyes of cargo_run (wrong), but cargo_compile produces only one binary (correct), making cargo_run bail unnecessarily:

// BEGIN Cargo.toml
[package]
name = "foo"
version = "0.1.0"
authors = []

[features]
default = [ "with-api-2" ]
# Names are chosen to suggest that there is some
# "default behavior" one could reasonably expect.
with-api-1 = []
with-api-2 = []

[[bin]]
name = "foobar1"
path = "src/main_v1.rs"
required-features = ["with-api-1"]

[[bin]]
name = "foobar2"
path = "src/main_v2.rs"
required-features = ["with-api-2"]
// END Cargo.toml
// BEGIN src/main_v1.rs
fn main() {
    println!("please pretend that this provides some API v1");
}
// END src/main_v1.rs
// BEGIN src/main_v2.rs
fn main() {
    println!("please pretend that this provides some API v2");
}
// END src/main_v2.rs

Behavior:

$ cargo run
error: `cargo run` requires that a project only have one executable; use the `--bin` option to specify which one to run
$

This might also be helpful for users having issue #2200.

[BenWiederhake]

Just compiling first and do any checks (e.g. "there is exactly one binary") afterwards doesn't work, as this would be a performance bug (unnecessarily slow) and many tests check for stdout, which would "suddenly" also contain compilation.

Refactoring cargo_compile.rs so that the outside modules can inspect the target list is probably the way to go.

Improving cargo_run's emulation of cargo_compile would probably handle this counter-example, but not others. Furthermore, I believe it's a bad idea to duplicate so much logic.

[alexcrichton]

cc @jbendig

[jbendig]

Thanks for reporting this issue! This is definitely wrong and I can reproduce it. I'll work on fixing it.

[BenWiederhake]

Awesome, thank you! Please have a look at some thoughts I gave about this, and why it looks to me like that this will need a refactor of cargo_compile.rs.

[jbendig]

@BenWiederhake Thanks! I'll take a look.