Incorrect dev-dependency feature resolution in workspace

[gildaf]

Problem

If a Cargo.toml of a package within a workspace is using the same crate in dependencies and dev-dependencies but with additional feature in dev-dependency that feature-flag will be used even when running in regular build (not a test) .

This seems pretty similar to #1796 but it only happens in a workspace.

Steps

• If you prefer you can just clone and run this repository

create a workspace with two packages. one package should be a binary (core in my example) and the other a lib (get_str).

├── Cargo.toml
├── core
│   ├── Cargo.toml
│   └── src
│       └── main.rs
└── get_str
    ├── Cargo.toml
    └── src
        └── lib.rs

./Cargo.toml

[workspace]
members = ["core", "get_str" ]

core/Cargo.toml

[package]
name = "bad-deps"
version = "0.1.0"
edition = "2021"

[dependencies]
get_str = { path = "../get_str" }

[dev-dependencies]
get_str = { path = "../get_str" , features = ["test"]}

core/src/main

fn main() {
    let s = get_str::get_string();
    println!("This is ... {}", s);
}

get_str/Cargo.toml

[package]
name = "get_str"
version = "0.1.0"
edition = "2021"

[features]
test = []

get_str/src/lib.rs

pub fn get_string() -> String {
    if cfg!(feature = "test") {
        "a test".to_string()
    } else {
        "not a test".to_string()
    }
}

Now just run cargo run . it should print This is ... not a test but it prints This is ... a test .
I reproduced it on cargo 1.58 and 1.61) .

Possible Solution(s)

No response

Notes

In the provided example the dependent crate is part of the workspace but it gets reproduced even if the crate is downloaded from crates.io .

Version

cargo 1.58.0 (f01b232bc 2022-01-19)
release: 1.58.0
commit-hash: f01b232bc7f4d94f0c4603930a5a96277715eb8c
commit-date: 2022-01-19
host: x86_64-apple-darwin
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.64.1 (sys:0.4.51+curl-7.80.0 system ssl:(SecureTransport) LibreSSL/2.8.3)
os: Mac OS 11.6.4 [64-bit]

[ehuss]

There are different feature resolver behaviors selected with the resolver setting. With a single package, the 2021 edition implicitly selects version "2". With a virtual workspace, there is no edition to select, so it defaults to the original version "1". You have to set the resolver field in the workspace. More can be found here.