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

  1. Remove `ws` from your -Zfeatures value (use `all`, or specific flags like `itarget`, `dev_dep`, `build_dep`).
  2. If you want the broadest decoupling, use -Zfeatures=all which sets decouple_host_deps, decouple_dev_deps, and ignore_inactive_targets.
  3. Check the Cargo version and the tracking issue (rust-lang/cargo) to see whether `ws` has been implemented in your nightly.
  4. 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

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


AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/e3f199f3bb3b1dbe.json. Report an issue: GitHub.