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.