Improve error message when wrong package found in a path dependency

[ehuss]

When specifying a path dependency, but the path has a different package there, the error message can be a little confusing.

For example:

[package]
name = "foo"
version = "0.1.0"

[dependencies]
definitely_not_bar = { path = "crates/bar" }

and crates/bar contains a bar package.

This will result in the error message:

error: no matching package named `definitely_not_bar` found
location searched: /Users/eric/Temp/foo/crates/bar
required by package `foo v0.1.0 (/Users/eric/Temp/foo)`

There are a few issues with this message:

• Doesn't explain that there was a different package found at that location.
• "location searched" implies it was doing a recursive search like it does with a git dependency, but it doesn't do that.
• It would be nice if hitting this situation if cargo could recursive search and tell you what the correct path would be. This recursive search should probably be bounded so it doesn't try too hard to find it.
  • It would be nice if this recursive search also worked for the case where a path dependency points to a directory without a Cargo.toml. Currently that error message looks like:

    error: failed to get `bar` as a dependency of package `foo v0.1.0 (/Users/eric/Temp/foo)`
    
    Caused by:
      failed to load source for dependency `bar`
    
    Caused by:
      Unable to update /Users/eric/Temp/foo/crates
    
    Caused by:
      failed to read `/Users/eric/Temp/foo/crates/Cargo.toml`
    
    Caused by:
      No such file or directory (os error 2)
    

    which isn't bad, but it would be nice if it was better and told you where it is found.

This issue came up in #13360, where a user converted a git dependency to a path dependency, and didn't know cargo wouldn't do a recursive search. The git path happened to have a Cargo.toml at the root.

Meta

cargo 1.87.0-nightly (2622e844b 2025-02-28)
release: 1.87.0-nightly
commit-hash: 2622e844bc1e2e6123e54e94e4706f7b6195ce3d
commit-date: 2025-02-28
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.7.1 (sys:0.4.79+curl-8.12.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.4.1 11 Feb 2025
os: Mac OS 14.6.1 [64-bit]

[epage]

path is managed in PathSource. git wraps a RecursivePathSource. Hopefully we can have the error case reuse RecursivePathSource for this lookup to keep things simple.

[secona]

Hi! Is anyone currently working on this, or would it be okay if I took a shot at it?

[weihanglo]

AFAIK, no. Feel free to do so. Or even better, use @rustbot to claim the issue.

[secona]

@rustbot claim