fix(path): clarify error message when path dependency has wrong package#16927
fix(path): clarify error message when path dependency has wrong package#16927raushan728 wants to merge 2 commits intorust-lang:masterfrom
Conversation
rustbot
added
A-dependency-resolution
|
r? @epage rustbot has assigned @epage. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| pub fn load(&self) -> CargoResult<()> { | ||
| let mut package = self.package.borrow_mut(); | ||
| if package.is_none() { | ||
| if !self.path.join("Cargo.toml").exists() { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
From #16927 (comment)
Note for reviewers: The change in
registry.rsis needed to handle case 2 and case 3 (wherebar/exists as a directory but has noCargo.toml). Without it the IO error fires before the resolver reachesactivation_error_path_hints. The suppression is guarded by three conditions: path source, typedManifestErrorwithNotFound, andhas_nearby_manifestsconfirming subdirectory packages exist.
This comment has been minimized.
This comment has been minimized.
| 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())) |
There was a problem hiding this comment.
This has really ballooned in complexity, including the idea of "catching" specific errors.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
From #16927 (comment)
Regarding
registry.rs- every alternative approach I tried but they broke existing tests. This is the cleanest I could find while keeping everything green.
There was a problem hiding this comment.
I have strong reservations about this approach and would need to understand why there is no other way, rather than being told that.
There was a problem hiding this comment.
@epage I found a approach may be it help - catching the missing manifest in PathSource::query() and returning Ok(()) with zero candidates, similar to how RecursivePathSource already silently skips missing manifests. This removes all the interception machinery from registry.rs entirely. Would this approach work for you?
There was a problem hiding this comment.
Implemented the PathSource::query() approach catching missing manifest there and returning Ok(()) with zero candidates. This removes all the interception machinery from registry.rs entirely.
There was a problem hiding this comment.
Why can't read_package return a CargoResult<Option<_>>, returning Ok(None) if the file does not exist?
Also, any change along these lines would likely be best done in a commit before the rest so help isolate behavior/test changes
raushan728
force-pushed
the
fix-15296
branch
3 times, most recently
from
d5f8d89 to
603d687
Compare
This comment was marked as duplicate.
This comment was marked as duplicate.
| let _ = writeln!( | ||
| &mut msg, | ||
| "no matching package named `{}` found at `{}`", | ||
| dep.package_name(), | ||
| rel_path(&path), | ||
| ); | ||
| let _ = write!( | ||
| &mut msg, | ||
| "required by {}", | ||
| describe_path_in_context(resolver_ctx, &parent.package_id()), | ||
| ); |
There was a problem hiding this comment.
Why does is_handled_custom_path_error till exist?
On the surface, it looks like we use it to move the location searched: message into the line before it but it isn't clear why we feel that complexity is worth it.
There was a problem hiding this comment.
It prevents location searched from appearing in the alt_paths branch without it, location searched would also appear for path hint errors where it's redundant since we already show the path in the error message.
There was a problem hiding this comment.
That was what my second paragraph was about which ends with
but it isn't clear why we feel that complexity is worth it.
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Since PathSource::query() now returns zero candidates for missing Cargo.toml instead of an IO error, some existing tests that expected the old error chain now show the resolver-level error message instead. |
3 participants
View all comments
Fixes #15296
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.