Workspace dependency features don't resolve correctly with target-dependent features

[zkat]

Problem

When using [workspace.dependencies] and foo = { workspace = true }, resolver v2 doesn't seem to correctly load only the features for the current target. Everything works fine if the package version is specified directly in the subcrate.

For example, given this Cargo.toml:

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
foo = { workspace = true }

[target.'cfg(target_arch = "wasm32")'.dependencies]
foo = { workspace = true, default-features = false }

Then if the crate is built with cargo build --target wasm32-unknown-unknown, foo will fail to build because it tries to compile wasm-incompatible code.

At the same time, the following works as expected:

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
foo = { version = "1.2.3" }

[target.'cfg(target_arch = "wasm32")'.dependencies]
foo = { version = "1.2.3", default-features = false }

Steps

1. Create a workspace with a [workspace.dependencies] field. I only tested this on a non-virtual workspace (one with a "root" crate). Add async-tar-wasm = "0.4.2-wasm.1".

2. Create a subcrate in that workspace with the following:

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
async-tar-wasm = { workspace = true }

[target.'cfg(target_arch = "wasm32")'.dependencies]
async-tar-wasm = { workspace = true, default-features = false }

3. Build with cargo build --target wasm32-unknown-unknown

Possible Solution(s)

No response

Notes

No response

Version

❯ cargo version --verbose
cargo 1.67.1 (8ecd4f20a 2023-01-10)
release: 1.67.1
commit-hash: 8ecd4f20a9efb626975ac18a016d480dc7183d9b
commit-date: 2023-01-10
host: x86_64-pc-windows-msvc
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:Schannel)
os: Windows 10.0.22621 (Windows 10 Enterprise) [64-bit]

[weihanglo]

Thank you for the issue report. This is the expected behavior as features are additive. The workspace dependency didn't opt-out default features, so inherited dependencies cannot get it off.

We made an improvement and will ship in the next version . See the changelog of 1.69 . This comment #11409 (comment) also summarize each combination very well.

[zkat]

Got it! Looks like this is all addressed, then. It was definitely surprising, though!