workspace.default-members causes cargo run --bin from-other-crate to fail with an unhelpful error

[kornelski]

Problem

In a workspace with default-members set, cargo run --bin considers only these members as expected. However, when specifying another workspace binary without -p, the error message is unhelpful, because it doesn't hint which package needs to be selected.

Steps

cargo run --bin other where the binary is in the workspace, but not in the default workspace member.

Possible Solution(s)

The error message could search other crates in the workspace and list which have a binary with the given name.

Notes

No response

Version

cargo 1.83.0-nightly (c1fa840a8 2024-08-29)
release: 1.83.0-nightly
commit-hash: c1fa840a85eca53818895901a53fae34247448b2
commit-date: 2024-08-29
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.0.0 [64-bit]

[epage]

Could you provide full reproduction steps and example failure output?

[kornelski]

cargo new crate1
cargo new crate2

• Cargo.toml at the root

[workspace]
members = ["crate1", "crate2"]
default-members = ["crate1"]

and

cargo r --bin crate2

gives

error: no bin target named `crate2`

    Did you mean `crate1`?

Alternatively, without default-members, cargo r --bin gives:

error: "--bin" takes one argument.
Available binaries:
    crate1
    crate2

with default-members it considers just the members, which is technically correct:

error: "--bin" takes one argument.
Available binaries:
    crate1

but it could be more helpful if it also looked at other workspace members and suggested -p to select them with their binaries.

[epage]

From a users perspective, it seems reasonable to improve. My only question is how much it would take to get the right information into the right place.