fix(path): clarify error message when path dependency has wrong package by raushan728 · Pull Request #16927 · rust-lang/cargo

raushan728 · 2026-04-22T10:39:39Z

When a path dependency specifies a package name that doesn't match what's
found at that path, Cargo now shows helpful hints about what packages exist
nearby instead of the confusing "location searched" message.

…rust-lang#15296)

rustbot · 2026-04-22T10:39:44Z

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage, weihanglo

epage

Thanks!

View changes since this review

epage · 2026-04-22T11:45:12Z

+                    crate::sources::RecursivePathSource::new(&path, dep.source_id(), gctx);
+
+                if let Ok(packages) = src.read_packages() {
+                    if !packages.is_empty() {


This is pretty deeply nested. I wonder if there is a better path for this.

This nesting has been refactored the logic is now extracted into a
standalone helper function activation_error_path_hints which returns
early with false for each guard condition, eliminating the deep nesting.
The call site in activation_error is now a single line.

epage · 2026-04-22T11:46:34Z

+                        for pkg in &packages {
+                            let p_name = pkg.name().as_str();
+                            if p_name == dep.package_name().as_str() {
+                                let _ = writeln!(


Should we be consistent in where we write the hints?

all hints now consistently written to hints buffer only

That wasn't what I meant. You have a loop for searching for items. In some cases it directly creates the hint and in some it handles it afterwards.

Fixed - the loop now only collects data (exact_match, found_dir,
names_found) and all hints are written after the loop ends.

epage · 2026-04-22T11:47:46Z

    pub fn load(&self) -> CargoResult<()> {
        let mut package = self.package.borrow_mut();
        if package.is_none() {
+            if !self.path.join("Cargo.toml").exists() {


Why was this added?

It was an earlier attempt to handle missing Cargo.toml - reverted because it was too broad and broke existing tests. Now i use typed error detection in registry.rs

From #16927 (comment)

Note for reviewers: The change in registry.rs is needed to handle case 2 and case 3 (where bar/ exists as a directory but has no Cargo.toml). Without it the IO error fires before the resolver reaches activation_error_path_hints. The suppression is guarded by three conditions: path source, typed ManifestError with NotFound, and has_nearby_manifests confirming subdirectory packages exist.

epage · 2026-04-22T11:51:33Z

+                            if s.is_empty() {
+                                s.push('.');
+                            }
+                            if !s.ends_with('/') {


Why are we doing this?

use file_name() to show the actual directory name (e.g. foo/) instead of ./ when the path equals the parent root

That isn't a complete sentence, making it harder to follow what you mean. I don't see how a file_name() (which?) even fits into this.

When path == parent_root, strip_prefix returns an empty string. In that case we fall back to path.file_name() to show the directory name (e.g. foo/) rather than an empty or confusing path

epage · 2026-04-22T11:53:37Z

+                        is_handled_custom_path_error = true;
+                        let _ = writeln!(
+                            &mut msg,
+                            "no matching package named `{}` found at `{}`\nnote: required by {}",


This adds a note on only this "required by",

Either we want this generally and a commit before this should add it or we should remove thisd

Looks like this was resolved by dropping the note:?

Yes, resolved by dropping the note: prefix.

raushan728 · 2026-04-23T12:43:07Z

Note for reviewers: The change in registry.rs is needed to handle
case 2 and case 3 (where bar/ exists as a directory but has no
Cargo.toml). Without it the IO error fires before the resolver
reaches activation_error_path_hints. The suppression is guarded by
three conditions: path source, typed ManifestError with NotFound,
and has_nearby_manifests confirming subdirectory packages exist.

epage · 2026-04-23T14:14:02Z

-    } else {
-        let _ = writeln!(
-            &mut msg,
-            "no matching package named `{}` found",
-            dep.package_name()
-        );
    }


This change involves a refactor where more things are put into the else branch, If this is kept, I'd recommend splitting that out into its own commit.

View changes since the review

the else branch restructuring is gone since we switched to the else if let Some(packages) = alt_paths(dep, gctx) pattern.

epage · 2026-04-23T14:14:40Z

-    let mut location_searched_msg = registry.describe_source(dep.source_id());
-    if location_searched_msg.is_empty() {
-        location_searched_msg = format!("{}", dep.source_id());
+    if !is_handled_custom_path_error {


We have two if !is_handled_custom_path_error in a row. Is there a reason these aren't merged and we just get rid of is_handled_custom_path_error?

View changes since the review

The two consecutive blocks are merged into one. The flag itself is still needed - location searched must appear for !candidates.is_empty() too.

epage · 2026-04-23T14:15:44Z

+    } else {
+        if activation_error_path_hints(dep, parent, gctx, resolver_ctx, &mut msg, &mut hints) {


If you make a function just for getting the recursive path source packages, you can keep the existing else-if pattern by having an } else if let Some(path_packages) = alt_paths(...)? { which I think will make this a bit cleaner / easier to follow

View changes since the review

Fixed - extracted alt_paths() function and using
} else if let Some(packages) = alt_paths(dep, gctx) { pattern.

epage · 2026-04-23T14:22:27Z

+            let res = source.query(dep, kind, f).await;
+            if let Err(e) = &res {
+                if dep.source_id().is_path()
+                    && crate::core::resolver::errors::is_manifest_not_found(e)
+                    && has_nearby_manifests(dep)
+                {
+                    return Ok(());
+                }
+            }
+            res.with_context(|| format!("unable to update {}", source.source_id()))


This has really ballooned in complexity, including the idea of "catching" specific errors.

View changes since the review

The registry.rs change was needed because without it, the IO error fires before the resolver reaches the diagnostic code for cases 2/3.

Is there a cleaner way you'd suggest to intercept this early failure so we can still provide helpful hints for those cases? Happy to rework the approach if you have a better path in mind.

…ge (rust-lang#15296) When a path dependency points to a directory with a different package, show which package exists there and where the correct one can be found.

raushan728 · 2026-04-24T07:08:32Z

Regarding registry.rs - every alternative approach I tried but they broke existing tests. This is the cleanest I could find while keeping everything green.

test(path): add tests for path dependency wrong package error message (…

2f317eb

…rust-lang#15296)

rustbot added A-dependency-resolution Area: dependency resolution and the resolver S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 22, 2026

rustbot assigned epage Apr 22, 2026

epage reviewed Apr 22, 2026

View reviewed changes

raushan728 force-pushed the fix-15296 branch from 1978dbb to bacfa17 Compare April 23, 2026 11:34

rustbot added the A-registries Area: registries label Apr 23, 2026

raushan728 requested a review from epage April 23, 2026 12:47

epage reviewed Apr 23, 2026

View reviewed changes

raushan728 force-pushed the fix-15296 branch 2 times, most recently from d4eb6f0 to d5f8d89 Compare April 24, 2026 06:09

fix(path): clarify error message when path dependency has wrong packa…

603d687

…ge (rust-lang#15296) When a path dependency points to a directory with a different package, show which package exists there and where the correct one can be found.

raushan728 force-pushed the fix-15296 branch from d5f8d89 to 603d687 Compare April 24, 2026 06:58

		} else {
		if activation_error_path_hints(dep, parent, gctx, resolver_ctx, &mut msg, &mut hints) {

Conversation

raushan728 commented Apr 22, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 22, 2026

Uh oh!

epage left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

raushan728 commented Apr 23, 2026

Uh oh!

epage Apr 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raushan728 Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Apr 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raushan728 Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Apr 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Apr 23, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raushan728 Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raushan728 commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

raushan728 commented Apr 22, 2026 •

edited by rustbot

Loading

epage left a comment •

edited by rustbot

Loading

epage Apr 23, 2026 •

edited by rustbot

Loading

raushan728 Apr 24, 2026 •

edited

Loading

epage Apr 23, 2026 •

edited by rustbot

Loading

raushan728 Apr 24, 2026 •

edited

Loading

epage Apr 23, 2026 •

edited by rustbot

Loading

epage Apr 23, 2026 •

edited by rustbot

Loading

raushan728 Apr 24, 2026 •

edited

Loading

raushan728 commented Apr 24, 2026 •

edited

Loading