rust-lang/cargo · critical
not implemented
Error message
not implemented
What it means
Originates in FeatureOpts::new (src/resolver/features.rs:189). The match over -Zfeatures options handles build_dep, host_dep, dev_dep, itarget, all, and compare, but the "ws" (workspace-wide feature unification) arm is a stub that calls unimplemented!(). The unimplemented!() macro panics at runtime with message "not implemented" rather than returning a Result. It exists because the workspace-scoped feature resolver variant was designed but never completed.
Source
Thrown at src/resolver/features.rs:189
ws: &Workspace<'_>,
has_dev_units: HasDevUnits,
force_all_targets: ForceAllTargets,
) -> CargoResult<FeatureOpts> {
let mut opts = FeatureOpts::default();
let unstable_flags = ws.gctx().cli_unstable();
let mut enable = |feat_opts: &Vec<String>| {
for opt in feat_opts {
match opt.as_ref() {
"build_dep" | "host_dep" => opts.decouple_host_deps = true,
"dev_dep" => opts.decouple_dev_deps = true,
"itarget" => opts.ignore_inactive_targets = true,
"all" => {
opts.decouple_host_deps = true;
opts.decouple_dev_deps = true;
opts.ignore_inactive_targets = true;
}
"compare" => opts.compare = true,
"ws" => unimplemented!(),
s => bail!("-Zfeatures flag `{}` is not supported", s),
}
}
Ok(())
};
if let Some(feat_opts) = unstable_flags.features.as_ref() {
enable(feat_opts)?;
}
match ws.resolve_behavior() {
ResolveBehavior::V1 => {}
ResolveBehavior::V2 | ResolveBehavior::V3 => {
enable(&vec!["all".to_string()]).unwrap();
}
}
if let HasDevUnits::Yes = has_dev_units {
// Dev deps cannot be decoupled when they are in use.
opts.decouple_dev_deps = false;
}View on GitHub (pinned to 0e07a15537)
Solutions
- Remove `ws` from your -Zfeatures value (use `all`, or specific flags like `itarget`, `dev_dep`, `build_dep`).
- If you want the broadest decoupling, use -Zfeatures=all which sets decouple_host_deps, decouple_dev_deps, and ignore_inactive_targets.
- Check the Cargo version and the tracking issue (rust-lang/cargo) to see whether `ws` has been implemented in your nightly.
- Switch to the stabilized v2/v3 resolver (resolver = "2"/"3" in Cargo.toml) which already enables the `all` flags internally.
Example fix
// before cargo +nightly build -Zfeatures=ws // after cargo +nightly build -Zfeatures=all
Defensive patterns
Strategy: validation
Validate before calling
// Filter unsupported -Zfeatures tokens before they reach FeatureOpts::new
fn sanitize_features_flags(flags: &mut Vec<String>) {
const UNSUPPORTED: &[&str] = &["ws"]; // unimplemented!() arms
flags.retain(|f| !UNSUPPORTED.contains(&f.as_str()));
}
// call before building the workspace / running cargo:
let mut f = config.cli_unstable().features.clone().unwrap_or_default();
sanitize_features_flags(&mut f); Type guard
// True when the -Zfeatures value set is safe (contains no unimplemented arms)
fn features_flags_are_safe(flags: Option<&Vec<String>>) -> bool {
match flags {
None => true,
Some(v) => !v.iter().any(|s| s == "ws"),
}
} Prevention
- Never use -Zfeatures=ws; prefer -Zfeatures=all for the broadest decoupling.
- Treat any -Zfeatures token not documented in your exact nightly's reference as suspect.
- Pin a known-good nightly in CI and assert on the set of unstable feature flags.
When it happens
Trigger: Passing -Zfeatures=ws on a nightly Cargo invocation (e.g. `cargo +nightly build -Zfeatures=ws`). The value reaches FeatureOpts::new only through ws.gctx().cli_unstable().features when the unstable features flag is populated with the token "ws".
Common situations: A developer copies the `ws` token from an old Cargo RFC, design doc, or stale blog post without realizing it was never finished. CI pinned to nightly with CARGO_UNSTABLE_FEATURES or a .cargo/config.toml [unstable] features = ["ws"] setting. Experimenting with feature-resolver flags documented as in-progress.
Related errors
- in the non-empty branch
- packages downloaded
- running the file `{cmd}` requires `-Zscript`
- `--edges public` requires `-Zunstable-options`
- resolve should have a single spec with resolved features
AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06).
Data as JSON: /data/errors/e3f199f3bb3b1dbe.json.
Report an issue: GitHub.