Binary project output within one workspace depends on build order

[mineichen]

Multiple projects within a workspace overwrite each others output, if their executable have the same name.

Imagine the following Cargo.toml snippet to be part of two projects (referred to as project_aand project_b):

[[bin]]
name = "runner"
path = "src/main.rs"

When compiling the workspace after a change in project_a, the following command runs the executable from project_a:

cargo run -p project_b --bin runner

Problems

1. I expected the -p flag to be considered or to rise a warning that it's being ignored in conjunction with --bin
2. Cargo workspaces allow two projects to target the same binary name, but currently names must be unique within the workspace

Possible Solution(s)

1. Deprecate -p and --bin to be used in conjunction
2. Fail workspace build if two projects use the same binary-name

Notes
Output of cargo version:

cargo 1.48.0 (65cbdd2dc 2020-10-14)

[ehuss]

The issue with -p is that Cargo doesn't know what created the runner binary, it just knows that it exists, and can only compare the timestamps of the files.

FWIW, if you attempt to build both packages at the same time, there's a giant warning that gets printed.

I hadn't really thought about the specific case of building them independently, and the fingerprinting failing. There's more discussion at #6293 (comment) about the concerns about outright rejecting duplicate targets in a workspace.

I'm uncertain how to fix this. Some ideas:

• Cargo could reject duplicates in a workspace, which could be very painful for a lot of projects that have duplicates (and things like [patch] bringing in examples that might have duplicate names).
• Cargo could track what created individual artifacts, but that seems like overkill.
• The deps directory layout could include hashes somewhere in the path for executables. Theres some notes about why this isn't done here, though maybe using hashed directory names might be an alternative.