Tracking issue for -Z features=dev_dep

[ehuss]

Implementation: #7820
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features

Summary
-Z features=dev_dep causes the feature resolver to prevent features enabled on dev dependencies from being enabled for normal dependencies. For example:

[dependencies]
serde = {version = "1.0", default-features = false}

[dev-dependencies]
serde = {version = "1.0", features = ["std"]}

In this example, the library will normally link against serde without the std feature. However, when built as a test or example, it will include the std feature.

This mode is ignored if you are building any test, bench, or example. That is, dev dependency features will still be unified if you run commands like cargo test or cargo build --all-targets.

Unresolved issues

• Update cargo metadata
• Does this cause existing projects to fail?
  • Projects can add missing features as a backwards-compatible workaround. However, if it causes problems for too many projects, we may need to find some way to opt-in.
• Does this significantly increase build times?
  • This can cause cargo test to rebuild some dependencies after a cargo build, where previously those dependencies were built once. Projects can add features to re-unify if they want, but it may not be clear or obvious what to add and when. We may need something that identifies these duplicate dependencies, and give suggestions on how to unify them. Or, we may need to make this opt-in somehow so the user needs to make this an explicit decision.
• Is it OK that this is a global mode?
  • For example, when running cargo test, binaries will use dependencies with the dev-dependency features. Changing this would be very difficult, requiring major changes to how Cargo builds its unit graph. It may also cause longer build times when it is not necessary, since common dependencies with different features would need to be built twice during cargo test.

[kvinwang]

Seems not working with build-dependencies?
Create a new empty crate with Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
authors = ["Kevin Wang"]
edition = "2018"

[dependencies]
log = {version = "0.4", default-features = false}

[build-dependencies]
bindgen = "0.49"

Build it with:

cargo +nightly build -Z features=dev_dep -Z build-std=core,alloc --target=x86_64-linux-kernel

Output:

error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-linux-kernel` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `log`.

Cargo version:

cargo 1.44.0-nightly (7019b3ed3 2020-03-17)

[ehuss]

@kvinwang there is a separate option for build dependencies (-Zfeatures=host_dep). Its tracking issue is #7915. dev_dep only affects dev-dependencies. See the link to the docs for more information.

[kvinwang]

there is a separate option for build dependencies

Ohh,-Zfeatures=build_dep works. Thanks very much!

[nrxus]

Would feature flags in dev-dependencys propagate as feature flags in regular dependencies do today or would they only affect the current crate since dev dependencies themselves do no propagate.

i.e.,

# crate-a:
[dev-dependencies]
crate-b = "1.1.0"
crate-c = { version = "0.1.0", features = ["foo"] }

# crate-b:
[dev-dependencies]
crate-c = { version = "0.1.0", features = ["bar"] }

Will crate-a be using features foo and bar when doing a cargo test (similarly to how it happens with normal dependencies), or only the foo feature since dev dependencies features do not propagate?

For what is worth I expect the latter since dev dependencies do not propagate so the features shouldn't either.

[ehuss]

dev-dependencies inside other dependencies are ignored the same as they are today.