Workspace dependency feature gets set by unrelated binary in same workspace

[SiebenCorgie]

Problem

I have a project with two binary crates as well as a common library crate. Both binaries depend on the library, but are unrelated to each other.
When activating a feature on one of the binaries the feature gets activated on the other binary as well. I'm not sure if that is intended.

I made a minimal case here.
shared_lib/src/lib.rs in the test case has two different return values, based on the state of my_feature.
bin1 does not set the feature, bin2 does. When executing cargo run --bin bin1 bin1 behaves as if the feature is set.

Steps

1. Have two binary crates in one workspace
2. Set a feature of a common dependency that lives in the same workspace for one of the binary crates
3. See that the feature is also set for the second binary crate

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.59.0-nightly (a359ce160 2021-12-14)
release: 1.59.0-nightly
commit-hash: a359ce16073401f28b84840da85b268aa3d37c88
commit-date: 2021-12-14
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: Arch Linux [64-bit]

[SiebenCorgie]

I also tested it on latest stable with the same result:

> cargo version --verbose
cargo 1.57.0 (b2e52d7ca 2021-10-21)
release: 1.57.0
commit-hash: b2e52d7cab0a286ee9fcc0c17510b1e72fcb53eb
commit-date: 2021-10-21
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.79.1-DEV (sys:0.4.49+curl-7.79.1 vendored ssl:OpenSSL/1.1.1l)
os: Arch Linux [64-bit]

[ehuss]

Thanks for the report! This is a known issue where using --bin bin1 implies --workspace in order to find where bin1 is located. The --workspace flag causes all features of all workspace members to be unified. You can instead use -p bin1 to tell cargo to only use the bin1 package.

Closing as a duplicate of #8157.