Features on dev-dependencies are added to the features on regular dependencies

[Maximkaaa]

Problem

If you have the same crate as a dependency both in dependencies and dev-dependencies, but with different set of features, the features from dev-dependencies are always used when compiling the crate. Even when we use this crate from another one, it's dev-dependencies features are still being applied.

Steps

1. Take an simple_asn1 crate as an example. It has time crate as dependency:

[dependencies]
...
time       = { default-features = false, version = "0.3", features = ["formatting", "macros", "parsing"] }

[dev-dependencies]
...
time = { default-features = false, version = "0.3", features = ["formatting", "macros", "parsing", "quickcheck"] }

2. Try to compile it for wasm32-unknown-unknown target. You get an error from getrandom crate:

maxim@maxbook:~/dev/simple_asn1$ cargo check --target wasm32-unknown-unknown
    Checking getrandom v0.2.6
   Compiling memchr v2.5.0
   Compiling log v0.4.17
error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
   --> /home/maxim/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.6/src/lib.rs:235:9
    |
235 | /         compile_error!("the wasm32-unknown-unknown target is not supported by \
236 | |                         default, you may need to enable the \"js\" feature. \
237 | |                         For more information see: \
238 | |                         https://docs.rs/getrandom/#webassembly-support");
    | |________________________________________________________________________^

error[E0433]: failed to resolve: use of undeclared crate or module `imp`
   --> /home/maxim/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.6/src/lib.rs:262:5
    |
262 |     imp::getrandom_inner(dest)
    |     ^^^ use of undeclared crate or module `imp`

3. Now comment out the dev-dependency time line (or just remove the quickcheck feature). Compilation succeeds with no problem.

The issue here is that time/quickcheck feature introduces a rand dependency that cannot be compiled for wasm32-unknown-unknown target (without a special feature). But this time/quickcheck feature should not be used at all here.

If we use simple_asn1 crate as a dependency, this time/quickcheck feature is also being used, breaking compilation.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.61.0 (a028ae4 2022-04-29)

[Eh2406]

Switch to edition = "2021" or add resolver = "2" in your cargo.toml. The documentation is at https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2

[Maximkaaa]

Yes, it does fix the issue in the declaring crate. But does it mean that if the error occurs in a dependency I'm out of luck (build still fails). Is my only option to ask the crate maintainer to update the crate?

[Eh2406]

The resolver = "2" setting is controlled by the root package. If you are building a project foo, and getting errors because features merge from dev-dependencies with dependencies, adding resolver = "2" to foo will fix it.

[Maximkaaa]

I'm pretty sure it's not, I'm testing it right now. Having:

[package]
edition = "2021"
resolver = "2"

[dependencies]
simple_asn1 = "0.6.1"

This produces a build error above when compiled for wasm32-unknown-unknown target.

[Eh2406]

That really looked like a bug for a few mins there! I had steps to reproduce all written up, and was ready to reopen. Then I checked if what is on github matched what was in the published version of the crate here.

[dependencies]
...
time       = { default-features = false, version = "0.3", features = ["formatting", "macros", "parsing", "quickcheck"] 

So that is why the quickcheck feature of time is part of the dependencies. Here is the PR where it was fixed. Looks like the fix has not yet bean published.

[Maximkaaa]

Wow, nice find! Thank @Eh2406 for your help.

[vdods]

I've run into this problem a few times, and discovering the source is time consuming and difficult (often involves traversing the gigantic cargo tree output to see which crates lead to the feature that's enabled). It was a bit confusing for me because all the crates in my workspace had edition = "2021" so I thought I was good. But I still had to add resolver = "2" into the workspace root Cargo.toml. This was rather confusing, but did work for me.

Anyway, the point I'm trying to make is that control over this behavior is confusing because it's not specified in a single place (the crate) and because it's controlled via the edition and(or?) the resolver.

Also relevant: rust-lang/rust#90148

[epage]

#10112 is the issue for linting for lack of resolver.