Support the `[features]` section in virtual manifests

[twistezo]

I have project structure:

+---workspace_a
¦   ¦   Cargo.toml
¦   ¦   
¦   +---src
¦           lib.rs
¦   Cargo.lock
¦   Cargo.toml

Main manifest ./Cargo.toml:

[workspace]
members = ["workspace_a"]

[dependencies.workspace_a]
path = "./workspace_a"

[features]
only_a = [
    "workspace_a/only_a"
]

Workspace manifest ./workspace_a/Cargo.toml:

[package]
name = "workspace_a"
version = "0.1.0"
authors = ["author.com"]

[features]
only_a = []

And ./workspace_a/lib.rs:

#[test]
fn test_a() {
    assert_eq!(1, 1);
}

#[cfg(not(feature = "only_a"))]
#[test]
fn test_b() {
    assert_eq!(1, 1);
}

When i'm in root and trying cargo test --all --features only_a virtual manifest doesn't see feature in my workspace.

It's working when i'm in ./workspace_a/ or when main manifest it's not virtual.

[alexcrichton]

Thanks for the report! Unfortunately though the [features] section doesn't work in Cargo.toml as a virtual manifest (without a [package] section, but we should probably warn about this!

[twistezo]

@alexcrichton any hope in future about this improvement ?

[alexcrichton]

@twistezo I'll tag it as a feature request.

[sanmai-NL]

I have a different issue, that fits under this as an ‘umbrella issue’. Given these conditions:

• The current working directory is the virtual workspace directory.
• The virtual workspace has a crate member.
• The crate member defines an executable in [[bin]] in the crate Cargo manifest.
• That executable requires a feature defined in the crate Cargo manifest.

Then this fails:

cargo run --package crate --bin other_executable --features other_executable_feature

error: target `other_executable` requires the features: `other_executable_feature`
Consider enabling them by passing e.g. `--features="other_executable_feature"`

Whereas this succeeds:

cargo run --package crate --bin other_executable --all-features

As well as this:

cd "${virtual_workspace_directory:?}" &&
cargo run --package crate --bin other_executable --features other_executable_feature

[Michel-Haber]

Any updates on this?

[matklad]

@Michel-Haber it's unclear what semantics exactly [features] section in the virtual manifest should have, and what exact problems that should solve. So, the "feature request" part of it is in "needs design" phase. AFAIK, nobody is working on it.

As for "--features flag has unexpected behavior with workspaces", we've tried to fix it in #5364, but that unfortunately broke code in the wild.

[Michel-Haber]

@matklad It seems reasonable to me for a workspace to be able to specify its features as re-exports of package features. i.e:

[features]
wsfeature = ["package1/feature1", "package2/feature2"]

A logical link may or may not exist between feature1 and feature2, but this allows for a cleaner selection of features for a set of projects, and, in its simplest form, would simply be a re-export of a package's feature.

This also fixes the unexpected behaviour of --features flag, since it becomes tied to the workspace itself, and not its packages.

[brendanzab]

This meant I wasted a bit of time today, so I linked the PR above. I just went with the --manifest-path workaround for now. That said I would have expected cargo build --features="codespan" to warn, and cargo build --features="moniker/codespan" to 'just work'.

[to-mas-kral]

Please add a warning, so other poeple know about this, that would've saved me a couple of hours.