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.

[linyihai]

The Available packages were retrieved by these functions

cargo/src/cargo/util/workspace.rs

Lines 12 to 18 in 3b784a4

	fn get_available_targets<'a>(
	filter_fn: fn(&Target) -> bool,
	ws: &'a Workspace<'_>,
	options: &'a CompileOptions,
	) -> CargoResult<Vec<&'a str>> {
	let packages = options.spec.get_packages(ws)?;

options.spec is a Packages::Default enum type.

cargo/src/cargo/ops/cargo_compile/packages.rs

Lines 114 to 120 in 3b784a4

	pub fn get_packages<'ws>(&self, ws: &'ws Workspace<'_>) -> CargoResult<Vec<&'ws Package>> {
	let packages: Vec<_> = match self {
	Packages::Default => ws.default_members().collect(),
	Packages::All(packages) => {
	emit_packages_not_found_within_workspace(ws, packages)?;
	ws.members().collect()
	}

So get_packages chose Packages::Default to get all default_members.

And See the default_members in the Workspace struct

cargo/src/cargo/core/workspace.rs

Lines 77 to 87 in 3b784a4

	/// The subset of `members` that are used by the
	/// `build`, `check`, `test`, and `bench` subcommands
	/// when no package is selected with `--package` / `-p` and `--workspace`
	/// is not used.
	///
	/// This is set by the `default-members` config
	/// in the `[workspace]` section.
	/// When unset, this is the same as `members` for virtual workspaces
	/// (`--workspace` is implied)
	/// or only the root package for non-virtual workspaces.
	default_members: Vec<PathBuf>,

This is explains why default_members unset, all members could be treated as Available

We could use Packages::All(Vec::new()).get_packages(ws)? to get all members in the get_available_targets