cargo test --all-features at the workspace level doesn't behave as I would expect

[tdelabro]

Problem

Let's say I have a request with two crates, a lib and a bin.

Cargo.toml

[workspace]
resolver = "2"
members = [
  "my_lib", "my_bin"
]

[workspace.dependencies]
my_lib = { path = "./my_lib" }

my_lib/Cargo.toml

[package]
name = "my_lib"
version = "0.1.0"
edition = "2021"

[dependencies]

[features]
default = []
feature_b = []

my_lib/src/lib.rs

pub struct MyStruct {
    pub a: u64,
    #[cfg(feature = "feature_b")]
    pub b: u64,
}

my_bin/Cargo.toml

[package]
name = "my_bin"
version = "0.1.0"
edition = "2021"


[dependencies]
my_lib = { workspace = true }

my_bin/src/main.rs

use my_lib::MyStruct;

fn main() {
    let my_struct = MyStruct { a: 42 };
    println!("{}", my_struct.a);
}

Running cargo check --all-features at the workspace level I get:

cargo check --all-features
    Checking my_lib v0.1.0 (/private/tmp/wrspc/my_lib)
    Checking my_bin v0.1.0 (/private/tmp/wrspc/my_bin)
error[E0063]: missing field `b` in initializer of `MyStruct`
 --> my_bin/src/main.rs:4:21
  |
4 |     let my_struct = MyStruct { a: 42 };
  |                     ^^^^^^^^ missing `b`

For more information about this error, try `rustc --explain E0063`.
error: could not compile `my_bin` (bin "my_bin") due to 1 previous error

Meaning it's compiling the my_bin using my_lib with feature.feature_b enabled.

To me it seems like an error, as the my_bin crate doesn't ever specify the use of the feature_b feature, which is not enabled by default in my_lib.

Proposed Solution

The behavior I would expect is:

• build my_lib with all ITS features enabled (here, feature_b)
• build my_bin with all ITS features enabled (here, none) but for it's dependencies, only add the features specified, not all existing

Notes

No response

[epage]

Cargo unifies features for a version of a package, rather than build two copies of it. So when you specify cargo check --all-features, all workspace members are selected and all features for all workspace members are enabled. The lib will then only be built once with all features enabled and then the bin will be built against that instance of the lib.

As noted in the feature unification documentation, features are expected to be additive, where enabling a feature should not break builds.

RFC #3692 proposed giving users more control over feature unification. Forcing more unification has been implemented but not reducing unification. Granted, this is not intended to work around non-additive features but to help with testing packages in isolation, much like what cargo hack provides.

We have several overlapping issues for feature unification already and so I'm going to close this in favor of #4463.