Feature that affects dev dependencies can't be enabled

[dtolnay]

Problem

I have crates A, B, C with the following manifests:

[package]
name = "a"
version = "0.0.0"

[features]
f = ["b/f"]

[dependencies]
b = { path = "../b" }

[package]
name = "b"
version = "0.0.0"

[features]
f = ["c/f"]

[dev-dependencies]
c = { path = "../c" }

[package]
name = "c"
version = "0.0.0"

[features]
f = []

Expected behavior: I believe it should be possible to build crate A. Running cargo check in crate A should build crate A without feature f and crate B without feature f. Running cargo check --features f in crate A should build crate A with feature f and crate B with feature f, but not C because that is a dev dependency of a dependency.

Actual behavior: crate A cannot be built, with or without f.

$ cargo check

error: failed to select a version for `b`.
    ... required by package `a v0.0.0 (/path/to/a)`
versions that meet the requirements `= 0.0.0` are: 0.0.0

the package `a` depends on `b`, with features: `c` but `b` does not have these features.


failed to select a version for `b` which could resolve this conflict

Possible objection: "but B/f requires C/f, we can't enable B/f without building C!" I don't think this is valid because cargo check --features f in crate B will already build crate B with feature f enabled without building the dev dependency C.

Notes
cargo 1.36.0-nightly (beb8fcb 2019-04-30)

[apopiak]

Is there a known workaround for this except moving the deps to the dependencies section?

[epage]

I ran

$ cargo new --lib a
$ cargo new --lib b
$ cargo new --lib c

And replaced the Cargo.tomls with what was in the Issee.

I then ran

$ cargo check
$ cargo check -F f

And it worked.

Seems like this was fixed (maybe when weak/namespaced features were added?). Closing. If there is something I missed, let us know!

[dtolnay]

Thank you!

The fix bisects to nightly-2021-11-24. The commit range is rust-lang/rust@936f260...65c55bf, in which the only Cargo update is rust-lang/rust#91144. In there, I bet it was #10103, although the PR description does not directly describe the scenario in this issue.

[dtolnay]

Confirmed it was #10103.

Glad this works! Hopefully it stays that way — would it be worth reopening this issue to track adding a dedicated test, or are the tests added by #10103 focused on feature cycles good enough coverage for this case?

I'll take a look through the tests myself and send a PR.