Don't pass --features from dev-dependencies to dependencies

[valarauca]

Working on a smallish project.

The main reason this came up was nom. Which has a feature flag that gates its new errors linky. If I include a dependency my whole build breaks as a dev-dependency is building nom with verbose errors.

[roblabla]

I have a similar issue, but with bindgen as a build-dependencies and libc as a dependencies in a nostd project.

Basically, bindgen depends (eventually) on libc (compiled with the default features, and so requires std). I'm building libc with nostd (my project is meant to be ran on a custom target with no std support), but it fails, saying it cannot find the crate std. If we turn on the verbosity of cargo, we can clearly see the use_std feature being passed to libc. Here's what I have : https://gist.github.com/anonymous/a42cc000486d5551d3849f3517d4b3a7

[radix]

I have this problem too, working with serde in project with optional std support: https://github.com/radix/uom/blob/serde/Cargo.toml

If I'm building this uom branch with cargo build --features f32,serde --no-default-features, it still builds serde with std support. This is because the serde_json dependency in dev-dependencies depends on serde with default features. This is strange, because serde_json isn't even being built!

Shouldn't this be a bug instead of a feature-request?

[radix]

btw this seems related to, or maybe the same as #4361

[roblabla]

it's related yeah. 4361 is about build-deps, we're about dev-deps, but a fix for one should probably fix the other.

[Eh2406]

This appears to be related to #2589

[mbrubeck]

Also duplicated by #4866.

[tarcieri]

#2589 and #4866 appear to be the same as this issue to me.

Of these three, I prefer the write up in #4866

[dwijnand]

Duplicate of #4866

[Nemo157]

#4866 is referring to build-dependencies in its OP, despite the title saying dev-dependencies. #2589 and #4866 are duplicates about build-dependencies features affecting dependencies always, while this is in relation to features from dev-dependencies affecting cargo build in a crate (or also when included as a path dependency of another crate when in a workspace). It's a bit different in that dev-dependencies should affect (public) dependencies features when running cargo test, as the dependency used in the tests needs to match the dependency used in the build.

[ehuss]

Non-unification of dev-dependency features has been implemented and is available as a nightly-only feature on the latest nightly 2020-02-23. See the tracking issue at #7916.

If people following this issue could try it out, and leave your feedback on the tracking issue (#7916), I would appreciate it. Particularly we'd like to know if it helps your project, does it cause any breakage, and is it a problem that binaries are still unified with cargo test?