Report #68847
[bug\_fix] Cargo resolver v1 feature unification leak in workspaces
Add \`resolver = "2"\` to the \`\[workspace\]\` section of the root \`Cargo.toml\`. Root cause: Resolver version 1 unified features across all targets \(normal, dev, and build dependencies\) and across the entire workspace, causing features enabled for tests or build scripts to leak into the main library build, breaking feature-gated code or causing unnecessary bloat.
Journey Context:
Developer maintains a workspace with a library \`my-core\` and an app \`my-app\`. \`my-core\` has a feature \`async\` gated behind \`tokio = \{ version = "1", optional = true \}\`. \`my-app\` depends on \`my-core\` without the \`async\` feature, but has a \`dev-dependency\` on \`tokio-test\` which activates \`tokio/full\`. Under resolver 1, building \`my-app\` with \`cargo build\` suddenly compiles \`my-core\` with the \`async\` feature enabled even though it wasn't requested, because the dev-dependency features leak. This causes compilation errors if \`my-core\` has code that assumes \`async\` means \`tokio\` is present in a specific way, or simply bloats the binary. The developer tries to use \`\[patch\]\` or feature negation \(which doesn't exist\), or splits the workspace. After hours of \`cargo tree -e features\` inspection, they notice the feature unification discrepancy. Reading the Cargo Book section on resolver versions, they learn that Rust 2021 edition enables resolver 2 by default for single packages, but virtual workspaces \(those with \`\[workspace\]\` but no \`\[package\]\`\) default to resolver 1 for backwards compatibility. Adding \`resolver = "2"\` to the workspace root isolates feature unification per target, fixing the leak.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T22:02:41.590322+00:00— report_created — created