`{feature}` is unsupported when inferring the crate name, us

Error message

`{feature}` is unsupported when inferring the crate name, use `{dep_feature}`

What it means

From parse_dependencies (src/bin/cargo/commands/add.rs:317-326). When a crate name is being inferred (infer_crate_name is true, set when --path or --git is given with no explicit crate), the DepFeature variant (dep/feature syntax) is rejected because the dependency name is not yet known and cannot be matched against the crates IndexMap. Cargo tells you to use the bare feature name instead.

Source

Thrown at src/bin/cargo/commands/add.rs:323

                    );
                }
                crates
                    .first_mut()
                    .expect("always at least one crate")
                    .1
                    .get_or_insert_with(IndexSet::default)
                    .insert(feature.to_owned());
            }
            FeatureValue::Dep { .. } => {
                anyhow::bail!("feature `{feature}` is not allowed to use explicit `dep:` syntax",)
            }
            FeatureValue::DepFeature {
                dep_name,
                dep_feature,
                ..
            } => {
                if infer_crate_name {
                    anyhow::bail!(
                        "`{feature}` is unsupported when inferring the crate name, use `{dep_feature}`"
                    );
                }
                if dep_feature.contains('/') {
                    anyhow::bail!("multiple slashes in feature `{feature}` is not allowed");
                }
                crates.get_mut(&Some(dep_name.as_str().to_owned())).ok_or_else(|| {
                    anyhow::format_err!("feature `{dep_feature}` activated for crate `{dep_name}` but the crate wasn't specified")
                })?
                    .get_or_insert_with(IndexSet::default)
                    .insert(dep_feature.as_str().to_owned());
            }
        }
    }

    let mut deps: Vec<DepOp> = Vec::new();
    for (crate_spec, features) in crates {
        let dep = DepOp {

View on GitHub (pinned to 0e07a15537)

Solutions

Use the bare feature name: `--features derive`.
Pass the explicit crate name so it is not inferred, then `dep/feature` becomes valid: name the crate explicitly and use `--features <crate>/<feature>` only when not inferring (note: with an explicit name the code still expects the feature attached to that crate).
Edit Cargo.toml directly if you need precise control.

Example fix

// before
cargo add --git https://github.com/... --features mycrate/derive

// after
cargo add --git https://github.com/... --features derive

Defensive patterns

Strategy: validation

Validate before calling

// When adding from --path/--git (inferred name), require bare feature names
fn features_ok_for_infer(features: &[String], inferring: bool) -> bool {
    if !inferring { return true; }
    features.iter().all(|f| !f.contains('/'))
}

Type guard

fn is_bare_feature(f: &str) -> bool {
    !f.contains('/')
}

Prevention

With --path/--git and no explicit crate name, use bare feature names only.
Pass an explicit crate name if you need dep/feature qualification.

When it happens

Trigger: `cargo add --git https://... --features serde/derive` where the crate name is inferred from the git source, so qualifying with `serde/derive` cannot be resolved.

Common situations: Adding from a path/git source and copying a feature spec from elsewhere that qualifies the dep name; the inferred crate name differs from what you assumed.

Related errors

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