WIP: wrote 3 tests about improving the error message in the path dependency by ibilalkayy · Pull Request #16138 · rust-lang/cargo

ibilalkayy · 2025-10-22T14:11:37Z

What does this PR try to resolve?

This PR is trying to improve the error message when the wrong package is found in the path dependency. Currently the PR started from the tests.

How to test and review this PR?

There are 3 tests added that cover each case that is brought up in this issue.

invalid_package_name_in_path()
- It reads the main manifest file to find that the definitely_not_bar exists in the crates/bar and it goes to the crates/bar to find that it is not present there and it gives the error.
invalid_package_in_subdirectory()
- It reads the main manifest file to find that the definitely_not_bar exists in the crates/bar and after going there, it does not find it. Then it goes more deeper in the definitely_not_bar to find that the manifest file exists there and give use the helpful message.
invalid_manifest_in_path()
- It reads the main manifest file to find that definitely_not_bar exists in the crates/bar but after going there, it finds that there are other two packages but definitely_not_bar is not present and it gives the message.

rustbot · 2025-10-22T14:11:42Z

r? @ehuss

rustbot has assigned @ehuss.
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

ibilalkayy · 2025-10-29T16:38:30Z

@epage I noticed that there were 7 spaces missing on both lines. So I added them and the test got passed.

I have squashed and pushed the code, but these spaces are not showing. Maybe it's a GitHub thing.

There is a conflict that came after your changes. Should I resolve the error by keeping this function or remove it?

function get_codegen_section_x(sections) {...}

weihanglo · 2025-11-26T15:22:44Z

 use super::context::ResolverContext;
 use super::types::{ConflictMap, ConflictReason};

+fn debug_source_path() {


If these are for local debugging purpose, please remove.

This was showing where they are at in experimenting while they then work to change this to fit in

weihanglo · 2025-11-26T15:25:03Z

+            edition = "2015"
+            authors = []
+
+            [workspace]


Is [workspace] here essential? If not maybe we should remove.

epage · 2025-12-03T14:57:05Z

-    let gctx = GlobalContext::default().unwrap();
-    let sid = SourceId::for_path(path).unwrap();
-
+fn debug_source_path(msg: &mut String, path: &Path, gctx: &GlobalContext, sid: SourceId) {


These should go below where they are used so that the first item in the file is the starting point for reading it and going further down just adds more context

epage · 2026-01-29T21:44:53Z

-            &mut msg,
-            "no matching package named `{}` found",
-            dep.package_name()
-        );


This was moved from out of the else block, into it.

ibilalkayy · 2026-03-05T23:22:26Z

Hey @epage, I have now written my doubts and confusion in the comment that you can review it.

Here is the code where I wrote comment: https://github.com/rust-lang/cargo/pull/16138/changes

There is one functionality about the invalid_manifest_in_path remaining that needs to be written and called out

Plus I am not sure why the tests are passing locally but failing here with these two functions.

epage · 2026-03-06T19:01:42Z

+        .with_status(101)
+        .with_stderr_data(str![[r#"
+[ERROR] no matching package named `bar` found at `definitely_not_bar`
+[NOTE] required by package `foo v0.5.0 ([ROOT]/foo)`


I'm assuming this test is failing. Tests should be atomic which includes tests passing. This should be showing the existing behavior so that the following commit then changes that behavior so we can see the new behavior.

epage · 2026-03-06T19:02:26Z

+
+            let global_context = match gctx {
+                Some(context) => context,
+                None => &GlobalContext::new(Shell::new(), PathBuf::new(), PathBuf::new()),


It seems suspicious for us to create global contexts on the fly

epage · 2026-03-06T19:04:50Z

+                    &mut msg,
+                    "no matching package named `{}` found at `{}`",
+                    name.name,
+                    dep.package_name()


Grammatically, this reads in an odd way.

"at" in a situation like this implies a location which would likely to be assumed to be a path but to say "package foo not found in package bar" is odd because they are both packages and a package cannot have packages inside of it.

I would instead recommend having a note naming the package that does exist at a specific path

epage · 2026-03-06T19:05:57Z

+            let root_package =
+                inspect_root_package(&mut msg, Path::new(&path), global_context, sid);
+
+            if let Some(name) = root_package {


what happens if a root package is not found?

epage · 2026-03-06T19:06:45Z

+) -> Option<RootPackageInfo> {
+    let mut ps = PathSource::new(path, sid, gctx);
+
+    ps.root_package().expect("failed to get the root");


expects are an assert and should name the condition that is upholding this ("I expect foo to be true")

epage · 2026-03-06T19:06:49Z

+                .source_id()
+                .url()
+                .to_file_path()
+                .expect("[ERROR]: failed to get the path");


expects are an assert and should name the condition that is upholding this ("I expect foo to be true")

epage · 2026-03-06T19:08:06Z

+
+    let pkg = ps
+        .read_package()
+        .expect("failed to read the package in root");


Why are we getting the root package, throwing it away, then calling read_package?

epage · 2026-03-06T19:08:32Z

+        .read_package()
+        .expect("failed to read the package in root");
+
+    let package_info = RootPackageInfo {


Why do we need a struct for this?

epage · 2026-03-06T19:09:38Z

+                let _ = writeln!(
+                    &mut msg,
+                    "help: package `{}` exists at `{}`",
+                    name.name, name.name


The at is giving the package name

epage · 2026-03-06T19:09:50Z

+                let _ = writeln!(
+                    &mut msg,
+                    "help: package `{}` exists at `{}`",
+                    name.name, name.name


epage · 2026-03-06T19:10:26Z

+    _path: PathBuf,
+}
+
+fn inspect_recursive_packages(


this name doesn't say what it is doing

epage · 2026-03-06T19:10:45Z

+    msg: &mut String,
+    path: &Path,
+    gctx: &GlobalContext,
+    sid: SourceId,
+) -> Option<RootPackageInfo> {


A bit unusual to have a function like this also modify msg

epage · 2026-03-06T19:10:49Z

+}
+
+fn inspect_recursive_packages(
+    msg: &mut String,


A bit unusual to have a function like this also modify msg

epage · 2026-03-06T19:11:20Z

+            } else if let Some(name) = recursive_packages {
+                let _ = writeln!(
+                    &mut msg,
+                    "no matching package named `{}` found at `{}`",


We sure are repeating this a lot

epage · 2026-03-06T19:12:20Z

+            let manifest = pkg.manifest_path();
+            let pkg_dir = manifest
+                .parent()
+                .expect("failed to take the parent path")


ditto about expect

epage · 2026-03-06T19:12:32Z

+            // } else {
+            //     let list = rps.list_files(&pkg).unwrap();
+            //     println!("{:?}", list);


epage · 2026-03-06T19:12:40Z

+            let package_info = RecursivePackageInfo {
+                name: pkg.name().to_string(),
+                _path: pkg_dir,
+            };


Why a struct?

…r path dependencies

…pendency

…ges for path dependencies

ibilalkayy · 2026-03-22T07:17:35Z

@epage As you have said, I should divide the tests into atomic commits by separating the actual and expected behaviour. I did it for the root package, and it worked, but for the recursive packages, the test is failing by asking me to write the actual behavior message, even though I want to change it.

The problem I noticed is that the logic is not even triggering the recursive package messages, and even if I make any change in the logic, it still gives the same old message of the actual behaviour. This thing prevents me from moving forward even after making multiple changes like

flipping the conditional statement b/w root and the recursive package.
instead of writing Some(package_name) = root_package and Some((package_name, package_path)) = recursive_packages under the last else statement, I continued the flow by putting more else if statements for these two conditions and wrote the else statement afterwards.

Both of these approaches didn't work. Plus, I also made the changes in the code as you said.

rustbot · 2026-03-27T15:37:55Z

☔ The latest upstream changes (possibly #16795) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot assigned ehuss Oct 22, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 22, 2025

epage marked this pull request as draft October 22, 2025 14:20

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 22, 2025

epage reviewed Oct 22, 2025

View reviewed changes

Comment thread tests/testsuite/path.rs Outdated

epage reviewed Oct 22, 2025

View reviewed changes

Comment thread tests/testsuite/path.rs Outdated

epage reviewed Oct 22, 2025

View reviewed changes

Comment thread tests/testsuite/path.rs Outdated

epage changed the title ~~wrote 3 tests about improving the error message in the path dependency~~ WIP: wrote 3 tests about improving the error message in the path dependency Oct 22, 2025

ibilalkayy force-pushed the path_dependency_msg_improvement branch from 2a4dc4d to 2bf90ff Compare October 29, 2025 14:15

epage reviewed Oct 29, 2025

View reviewed changes

Comment thread tests/testsuite/path.rs Outdated

ibilalkayy force-pushed the path_dependency_msg_improvement branch from 2bf90ff to 4d041ea Compare October 29, 2025 16:29

rustbot added A-cli-help Area: built-in command-line help A-completions Area: shell completions A-documenting-cargo-itself Area: Cargo's documentation A-timings Area: timings Command-test labels Oct 29, 2025

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. label Oct 29, 2025

ibilalkayy force-pushed the path_dependency_msg_improvement branch 3 times, most recently from a12c57e to 9c538bb Compare November 5, 2025 17:00

rustbot added the A-dependency-resolution Area: dependency resolution and the resolver label Nov 26, 2025

weihanglo reviewed Nov 26, 2025

View reviewed changes

epage reviewed Dec 3, 2025

View reviewed changes

ibilalkayy force-pushed the path_dependency_msg_improvement branch from a9a8dc1 to 9695b25 Compare January 13, 2026 07:23

epage reviewed Jan 29, 2026

View reviewed changes

ibilalkayy force-pushed the path_dependency_msg_improvement branch 2 times, most recently from 196d02a to a025762 Compare February 18, 2026 17:23

ibilalkayy requested a review from epage March 5, 2026 23:22

ibilalkayy force-pushed the path_dependency_msg_improvement branch 2 times, most recently from 754b8ad to 94cd203 Compare March 6, 2026 18:54

epage reviewed Mar 6, 2026

View reviewed changes

ibilalkayy added 2 commits March 15, 2026 08:24

test: write the existing behavior for mismatched root path dependency

d0fead0

fix: improved the current behaviour by inspecting the root package fo…

f216f9b

…r path dependencies

ibilalkayy force-pushed the path_dependency_msg_improvement branch from 94cd203 to f216f9b Compare March 18, 2026 11:13

ibilalkayy added 2 commits March 18, 2026 19:55

test: writes the existing behavior for mismatched sudirectory path de…

29c2c50

…pendency

fix: improved the current behaviour by inspecting the recursive packa…

951c119

…ges for path dependencies

ibilalkayy force-pushed the path_dependency_msg_improvement branch from f892af2 to 951c119 Compare March 22, 2026 07:06

ibilalkayy requested a review from epage March 22, 2026 07:18

Conversation

ibilalkayy commented Oct 22, 2025 • edited by epage Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Uh oh!

rustbot commented Oct 22, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

ibilalkayy commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

ibilalkayy commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

ibilalkayy commented Mar 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ibilalkayy commented Oct 22, 2025 •

edited by epage

Loading

ibilalkayy commented Oct 29, 2025 •

edited

Loading

ibilalkayy commented Mar 5, 2026 •

edited

Loading

ibilalkayy commented Mar 22, 2026 •

edited

Loading