"error[E0519]: the current crate is indistinguishable from one of its dependencies" does not always accurately describe the problem

[bridiver]

We were seeing error[E0519]: the current crate is indistinguishable from one of its dependencies in our build and couldn't really make sense of it because it was complaining about things like log crate inside html5ever. It turns out that chromium added https://source.chromium.org/chromium/chromium/src/+/main:build/rust/cargo_crate.gni;l=102?q=rustc_metadata&ss=chromium

_rustc_metadata = ""
  if (defined(invoker.rustc_metadata)) {
    _rustc_metadata = invoker.rustc_metadata
  } else if (defined(invoker.epoch)) {
    _rustc_metadata = invoker.epoch
  }

which defaults to using the epoch in -Cmetadata=${_rustc_metadata}
If you happen to have two different crates with the same symbol and same epoch (but different crate names), you'll get this error, but the description of the problem is confusing because it actually has nothing to do with crate names in this case it has the same crate-name log and was compiled with the same -C metadata arguments
The crate name appears to be irrelevant if you supply the same metadata arguments because we fixed it with this

_metadata = "0"
  if (defined(invoker.epoch)) {
    _metadata = invoker.epoch
  }
  if (defined(invoker.crate_name)) {
    _metadata += invoker.crate_name
  }

[rillian]

Possibly related:

• Possible Regression: Error: the current crate is indistinguishable from one of its dependencies #111349
• possible address sanitizer bug #111284

[rillian]

If I understand the issue correctly, the chromium build system is calling rustc with something like -C metadata=0.25 derived from the crate minor version, where cargo has a longer hash. This causes collisions for symbols defined in dependencies which happened to have the same version number. That is just an issue with how the compiler is invoked. So far so good.

However, like with #111284, the error message reported by the compiler was a bit indirect. It would be nice if it suggested e.g. to check for the crates built with the same -C metadata. Maybe especially if it doesn't look like what cargo supplies, or if the compiler can determine the indistinguishable crates have the same metadata tag?

[riking]

Bad error message selectoin was fixed in #111461

[icmccorm]

I'm also seeing this issue when I attempt to compile rustc with address sanitizer enabled. I'm using a nightly toolchain with -Zsanitizer=address instead of downloading the stage0 binaries. Switching between old and recent nightly toolchains, I see both the old message—the current crate is indistinguishable...—as well as the new message, can't find crate. Both are referring to clap_derive. If I remove -Zsanitizer=address, everything compiles just fine.

[barafael]

I'm seeing this issue when compiling my crate for coverage analysis using cargo-tarpaulin.

[misha-antonenko]

The problem described by @icmccorm also reproduces with -Zsanitizer=thread

Upd: maybe the reason is in missed -Zbuild-std, as here...