Feature unification does not happen for namespaced features for optional dependencies

[mladedav]

Problem

Namespaced features (dep:some-crate) are not unified across packages in a workspace. I haven't seen it mentioned anywhere that this would be the case.

Steps

I've created a repro here.

The gist is having in a workspace package a:

[package]
name = "a"
version = "0.1.0"
edition = "2024"

[dependencies]
common = { path = "../common", optional = true }

[features]
default = ["dep:common"]

and a package b:

[package]
name = "b"
version = "0.1.0"
edition = "2024"

[dependencies]
common = { path = "../common", optional = true }

[features]
default = []
non-default = ["dep:common"]

where b uses something from common.

Possible Solution(s)

• Unify the features, making the example in repro compile with cargo build -p a -p b, while cargo build -p b would be broken.
  or
• Document that feature unification does not happen for optional dependencies.

Notes

No response

Version

cargo 1.87.0 (99624be96 2025-05-06)
release: 1.87.0
commit-hash: 99624be96e9d213b0e9b1e36451271f24e4a41d8
commit-date: 2025-05-06
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.12.1-DEV (sys:0.4.80+curl-8.12.1 vendored ssl:OpenSSL/3.4.1)
ssl: OpenSSL 3.4.1 11 Feb 2025
os: Manjaro 25.0.0 (Zetar) [64-bit]

[epage]

If I'm understanding this correctly, you are expecting that enabling a/default will cause b/common to be enabled?

dep:common is different than b/common. Instead b/common enables dep::common.

Also, we have authorized the removal of implicit features in a future edition (RFC #3491). It was deferred out of Edition 2024 due to some complexity in the design we went with that might have us explore some further feature design improvements.

[mladedav]

I just somehow confused myself into thinking the two dep:common features should be unified for some reason but that makes about as much sense as unifying two crates' features that happen to have the same name.

Sorry for the noise!