Resolver 2 behaviour with target-dependant dep

help
1

Hey!

So I have a crate which has this in it's Cargo.toml:

[dev-dependencies]
assert_matches = "1.5"
criterion = "0.3"
gumdrop = "0.8"
proptest = "1"
rand_core = { version = "0.6", default-features = false, features = ["getrandom"] }
serde_json = "1"

[target.'cfg(all(target_arch = "wasm32", target_os = "unknown"))'.dev-dependencies]
getrandom = { version = "0.2", features = ["js"] }

As you see, we have rand_core with getrandom feature.

We JUST WANT TO MAKE SURE that the crate compiles to WASM-targets correctly.
But to do so, getrandom dependency is required with js feature set on.

Here, it's all good, since this is just a dev-dependency, we can define it with:
[target.'cfg(all(target_arch = "wasm32", target_os = "unknown"))'.dev-dependencies].

The problem comes when we select resolver = 2 in Cargo.toml in the workspace.
This, causes a compilation to fail for test build when we target wasmi-32 or wasm32-unknown-unknown.
If we do that, the only way on which the crate compiles to wasm-targets is if we change the following:

+ [target.'cfg(all(target_arch = "wasm32", target_os = "unknown"))'.dependencies]
- [target.'cfg(all(target_arch = "wasm32", target_os = "unknown"))'.dev-dependencies]

Instead if we select resolver = 1, the problem disappears.

This sounds really confusing to me as I've always internalized that resolver = 2 is the "Powerful" one. Meaning it can resolve multiple instances of the same dep with different features for example. Which was previously not feasible.

So it's confusing to see that resolver 1 solves this while 2 can't.

Does anyone know why this happens or if that's expected?

2

Source of the issue: fix: reset the changes introduced in `getrandom` import as dep by duguorong009 · Pull Request #286 · privacy-scaling-explorations/halo2 · GitHub

3

From Features - The Cargo Book

Dev-dependencies do not activate features unless building a target that needs them (like tests or examples).

In other words with the v2 resolver the js feature of getrandom will not be enabled if you make it a dev-depencency unless you are building a test or example.

Note that for halo2_proofs you are enabling the getrandom feature of rand_core outside of a dev-dependency. As this is the only place where you enable it unconditionally, you can likely make the getrandom dependency with js feature enabled a regular dependency just for halo2_proofs.

4

Note that for halo2_proofs you are enabling the getrandom feature of rand_core outside of a dev-dependency. As this is the only place where you enable it unconditionally, you can likely make the getrandom dependency with js feature enabled a regular dependency just for halo2_proofs.

Exactly! I agree!
That's why in the CI we run cargo build --tests. Such that this doesn't happen. And it fails anyway.. Which is confusing.