Enabling feature in optional dependency causes downloading of that dependency's metadata

[HactarCE]

Problem

Given three crates A, B, and C, such that:

• A depends on B
• B depends optionally on C
• feature F of B enables a feature on C via the ?/ syntax (e.g., feature_F = ["crate_C?/feature_F"])

Then enabling feature F on B causes the metadata for crate C to be fetched, even though C does not appear in the dependency graph for A.

Steps

1. Clone https://github.com/HactarCE/rhaideptest/tree/bug2 (branch bug2)
2. cargo check
3. Observe that toml_edit appears in the top-level Cargo.lock

Possible Solution(s)

No response

Notes

Removing "parse" in the list of requested features in the top-level Cargo.lock causes toml_edit to no longer be fetched. In other words, replace this line:

bug2_dep = { path = "bug2_dep", features = ["parse"] }

with this line:

bug2_dep = { path = "bug2_dep", features = [] }

I expect that both of these should behave the same with respect to whether toml_edit metadata is fetched, since the parse feature doesn't actually depend on toml_edit.

Version

cargo 1.86.0 (adf9b6ad1 2025-02-28)
release: 1.86.0
commit-hash: adf9b6ad14cfa10ff680d5806741a144f7163698
commit-date: 2025-02-28
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.7.1 (sys:0.4.79+curl-8.12.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.4.1 [64-bit]

[epage]

Could you speak to the end-user impact of this?

Note that we have #10801 for tracking end-user impact of them showing up in the lockfiles which has the additional affect of being included with Cargo.lock. In general, I would lean towards closing this as a duplicate of #10801. The symptoms are different but most of the root cause is the same and most of the end-user affect is being tracked in #10801.

[HactarCE]

In my case it only caused an issue because of #15481 (it was strange to have issues fetching a crate that I didn't even need).

I think it's a good idea to close this in favor of #10801.