cargo feature or bug?

[tcharding]

Currently if one removes the lock file then runs DO_FEATURE_MATRIX=true RUSTUP_TOOLCHAIN=1.48.0 contrib/test.sh we get an error

thread 'main' panicked at 'packages downloaded: failed to download `wasm-bindgen-test v0.3.37`

Caused by:
    0: unable to get packages from source
    1: failed to parse manifest at `/home/tobin/.cargo/registry/src/github.com-1ecc6299db9ec823/wasm-bindgen-test-0.3.37/Cargo.toml`
    2: feature `resolver` is required

However if we remove the following from the manifest the build is fine

[target.wasm32-unknown-unknown.dev-dependencies]
wasm-bindgen-test = "0.3"
getrandom = { version = "0.2", features = ["js"] }

I do not understand why cargo tries to pull down wasm-bingen-test if the target is not wasm32? Is this a feature or a bug?

[apoelstra]

I suspect it's a "feature". It allows the lockfile to be computed consistently and the output of e.g. cargo vendor to be consistent no matter what target you are computing them from.

And in particular, if this error meant that we couldn't compile on an actual wasm32 target (and I'd guess that it does, though for 1.48.0 this is a big "whatever", the JS ecosystem has no doubt been entirely replaced multiple times since 1.48.0 was out), this is something we'd like to know even if we didn't have a wasm target handy.