rust-lang/cargo · error

cannot add `{}` as a dependency to itself

Error message

cannot add `{}` as a dependency to itself

What it means

`cargo add` rejects adding a crate as a dependency of itself. After resolving a `--path` source, the code compares the resolved path's parent against the manifest's own directory; if they are equal the dependency resolves to the very package being edited, which would create a self-referential (cyclic) dependency declaration. This is a hard error because it cannot be serialized meaningfully into the manifest.

Source

Thrown at src/ops/cargo_add/mod.rs:136

        .get_table(&dep_table)
        .map(TomlItem::as_table)
        .map_or(true, |table_option| {
            table_option.map_or(true, |table| {
                table
                    .get_values()
                    .iter_mut()
                    .map(|(key, _)| {
                        // get_values key paths always have at least one key.
                        key.remove(0)
                    })
                    .is_sorted()
            })
        });
    for dep in deps {
        print_action_msg(&mut options.gctx.shell(), &dep, &dep_table)?;
        if let Some(Source::Path(src)) = dep.source() {
            if src.path == manifest.path.parent().unwrap_or_else(|| Path::new("")) {
                anyhow::bail!(
                    "cannot add `{}` as a dependency to itself",
                    manifest.package_name()?
                )
            }
        }

        let available_features = dep
            .available_features
            .keys()
            .map(|s| s.as_ref())
            .collect::<BTreeSet<&str>>();
        let mut unknown_features: Vec<&str> = Vec::new();
        if let Some(req_feats) = dep.features.as_ref() {
            let req_feats: BTreeSet<_> = req_feats.iter().map(|s| s.as_str()).collect();
            unknown_features.extend(req_feats.difference(&available_features).copied());
        }
        if let Some(inherited_features) = dep.inherited_features.as_ref() {
            let inherited_features: BTreeSet<_> =

View on GitHub (pinned to 0e07a15537)

Solutions

  1. Do not add the crate to itself; if you meant to add it to a *different* member, run `cargo add` from (or with `-p`) that other member.
  2. If you intended a dev/test cycle within the same crate, remove the `--path .` argument and restructure the code instead of declaring a self dependency.
  3. Verify the directory the path points to with `cargo metadata` to confirm it is not the current manifest's parent.

Example fix

# before (wrong, run inside my-crate)
cargo add --path .

# after (add to a different workspace member)
cargo add --path . -p other-crate
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the path source is not the manifest's own directory before calling add().
use std::path::Path;

fn is_self_add(manifest_path: &Path, dep_path: &Path) -> bool {
    let manifest_dir = manifest_path.parent().unwrap_or_else(|| Path::new(""));
    let canonical = std::fs::canonicalize(dep_path).unwrap_or_else(|_| dep_path.to_path_buf());
    canonical == manifest_dir
}

// if let Some(p) = &dep_op.path {
//     assert!(!is_self_add(&manifest_path, Path::new(p)), "refusing self-add");
// }

Prevention

When it happens

Trigger: Running `cargo add --path .` (or `--path` pointing at the package's own directory) from inside the crate you are editing, or `cargo add <self-name>` where path resolution lands on the current crate. The check at mod.rs:135 compares `src.path == manifest.path.parent()`.

Common situations: Workspace scaffolding scripts that run `cargo add <crate> --path .` against the current member, or mistaken automation that adds a crate to its own manifest. Also triggered when a crate name collides with a sibling directory that resolves back to itself.

Related errors


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