rust-lang/cargo · error · anyhow::Error

the crate `{}` depends on crate `{}` multiple times with dif

Error message

the crate `{}` depends on crate `{}` multiple times with different names

What it means

In `extern_crate_name_and_dep_name`: a single source crate (`from`) lists two or more dependency edges to the same target crate (`to`) that resolve to different extern crate names. Rust forbids a crate from depending on the same dependency twice under different `extern` names through the normal dependency graph, so the resolver rejects this when building the name mapping.

Source

Thrown at src/resolver/resolve.rs:430

        to: PackageId,
        to_target: &Target,
    ) -> CargoResult<(InternedString, Option<InternedString>)> {
        let empty_set: HashSet<Dependency> = HashSet::default();
        let deps = if from == to {
            &empty_set
        } else {
            self.dependencies_listed(from, to)
        };

        let target_crate_name = || (to_target.crate_name(), None);
        let mut name_pairs = deps.iter().map(|d| {
            d.explicit_name_in_toml()
                .map(|s| (s.as_str().replace("-", "_"), Some(s)))
                .unwrap_or_else(target_crate_name)
        });
        let (extern_crate_name, dep_name) = name_pairs.next().unwrap_or_else(target_crate_name);
        for (n, _) in name_pairs {
            anyhow::ensure!(
                n == extern_crate_name,
                "the crate `{}` depends on crate `{}` multiple times with different names",
                from,
                to,
            );
        }
        Ok((extern_crate_name.into(), dep_name))
    }

    fn dependencies_listed(&self, from: PackageId, to: PackageId) -> &HashSet<Dependency> {
        // We've got a dependency on `from` to `to`, but this dependency edge
        // may be affected by [replace]. If the `to` package is listed as the
        // target of a replacement (aka the key of a reverse replacement map)
        // then we try to find our dependency edge through that. If that fails
        // then we go down below assuming it's not replaced.
        //
        // Note that we don't treat `from` as if it's been replaced because
        // that's where the dependency originates from, and we only replace

View on GitHub (pinned to 0e07a15537)

Solutions

Consolidate the duplicate dependency into a single entry with one consistent name/alias.
If you need the crate under two configurations (e.g. normal + dev), use the same `package` rename in both tables.
Remove the redundant `Cargo.toml` dependency line causing the second edge to the same package.

Example fix

# before
[dependencies]
my-serde = { package = "serde", version = "1" }
[dev-dependencies]
serde2 = { package = "serde", version = "1" }
# after
[dependencies]
serde = "1"
[dev-dependencies]
serde = "1"

Defensive patterns

Strategy: validation

Validate before calling

# Lint Cargo.toml for duplicate target crates with different aliases:
# e.g. flag two keys with package = "<same crate>"
tomlq -r '.dependencies | to_entries[] | select(.value.package?) | "\(.value.package)\t\(.key)"' Cargo.toml \
  | sort | uniq -c | awk '$1>1{print "duplicate dependency:",$2}'

Prevention

List each external crate once in `Cargo.toml`; reuse it across `[dev-dependencies]` with the same name.
Use a single consistent `package = ` alias if renaming.
Run a manifest linter (e.g. `cargo-sort`, `cargo-deny`) in CI.

When it happens

Trigger: A `Cargo.toml` listing the same crate twice under different `package = ` rename keys, or as both a normal and dev/build dependency with conflicting `explicit_name_in_toml`, such that two dependency entries point at the same package id with different renamed identifiers. The `for (n, _) in name_pairs` loop finds a mismatched `n`.

Common situations: Renaming a dependency via `package =` in two dependency tables (normal + dev) inconsistently; copy-paste dependency entries; a `[dependencies]` and `[dev-dependencies]` block both pulling the same crate with different alias names.

Related errors

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