cargo tree -d incorrectly shows duplicate workspace dependency with resolver = "2"

[dima74]

Problem

Given workspace with three crates:

Where crate1 and crate2 use dep identically:

[dependencies]
dep = { path = "../dep", default-features = false }

Then cargo tree -d reports duplicate dep dependency

Steps

• Cargo.toml:

[workspace]
resolver = "2"
members = [
    "crates/crate1",
    "crates/crate2",
    "crates/dep",
]

• crates/crate1/Cargo.toml:

[package]
name = "crate1"
edition = "2021"

[dependencies]
dep = { path = "../dep", default-features = false }

• crates/crate2/Cargo.toml:

[package]
name = "crate2"
edition = "2021"

[lib]
proc-macro = true

[dependencies]
dep = { path = "../dep", default-features = false }

• crates/dep/Cargo.toml:

[package]
name = "dep"
edition = "2021"

[features]
default = ["foo"]
foo = []

• cargo tree -d:

dep v0.0.0 (.../crates/dep)
└── crate2 v0.0.0 (proc-macro) (.../crates/crate2)

dep v0.0.0 (.../crates/dep)
└── crate1 v0.0.0 (.../crates/crate1)

Possible Solution(s)

No response

Notes

All of this should be true for the issue to reproduce:

• resolver = "2"
• Either crate1 or crate2 is a proc macro
• dep has non-empty default-features

Version

cargo 1.83.0-nightly (c1fa840 2024-08-29)
release: 1.83.0-nightly
commit-hash: c1fa840
commit-date: 2024-08-29
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w 11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

[ehuss]

Thanks for the report! This is working as intended. The crates are duplicated because they are being built with different features. You can view the differences with the -f "{p} {f}" flag.

[weihanglo]

To expand what ehuss has said a bit, I believe that is because when there is feature unification, features from the workspace member dep have merged with those from dep as a dependency of crate1. And because of feature resolver v2 (specified by resolver = "2"), features from proc-macro would not be merged with normal runtime dependencies. Hence two separate trees.

Given this is intended, I am going to close this. Feel free to ask more questions if you had any!