Unrelated workspace members affect feature selection even with --bin, unless excluded

[ryoqun]

Problem

Understandably, cargo {test/check/build} --bin some-binary --bin ... only compiles needed dependent crates, ignoring other member crates of a workspace, which aren't part of the dependency graph.

However, those members crates affect feature selection. So, if unused crate A depends on crate C with feature=F, it always activates the feature even when building some bin from crate B, which depends on crate C without feature=F.

The workaround is to explicitly exclude unneeded crates with --exclude A.

While feature selection/unification should be additive and harmless most of time, it's desirable not to select unused features, due to various concerns including code sizes, longer compile times, etc.

Steps

1. clone https://github.com/ryoqun/feature-selection-without-excludes
2. run cargo build --bin bin-high --workspace --exclude bin-high-bad and see the command succeeds
3. run cargo build --bin bin-high and see the failure like this due to unexpected feature selection and unification:

   Compiling lib-low v0.0.0 (/path/to/repo/lib-low)
error: bad feature is activated
 --> lib-low/src/lib.rs:2:1
  |
2 | compile_error!("bad feature is activated");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `lib-low` (lib) due to 1 previous error

Possible Solution(s)

It seems that all feature selection/unification happens before restricting what to build according to --bin.

Ideally, unneeded features are disabled after the specified target selections. In other words, Step 3 above should just work like Step 2.

Notes

This is a bit similar to #4463

Version

$ cargo version --verbose
cargo 1.80.1 (376290515 2024-07-16)
release: 1.80.1
commit-hash: 37629051518c3df9ac2c1744589362a02ecafa99
commit-date: 2024-07-16
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 20.4.0 [64-bit]

[epage]

This looks to be a duplicate of #8157, so closing in favor of that. If there is a reason to keep this open separately, let us know!