-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite cargo-metadata support #122
Conversation
a21f5cf
to
9086b57
Compare
Two of them fail currently, the other doesn't but is still useful to validate the logic.
This should make cargo machete --with-metadata much more accurate. The previous version was able to get crate names (snake_case names usable in source files) from cargo metadata, but was unable to go back to the dependency spec written in Cargo.toml from that. As a result, --fix was broken. The mapping is complex because the published package can use a different name (see https://lib.rs/crates/md-5 for an example), the dependency spec can rename it again (through key = { package = … }), and keys with dashes are mapped to crate names with underscores. Two of these cases were broken, all of them now work. This also removes a hack that attempted to extract package names from cargo SourceIds. Those are opaque and have changed as recently as Rust 1.78 (Cargo.lock v4).
With [patch] sections, this may not be the case.
Experienced this bug too, hope that this pull request fixes is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long review time, life happened :)
Small code comments here, I'll address them myself if you don't get a chance to do it yourselves. Thanks for the contribution, especially the comments and tests helped me a lot.
// when a lib is renamed through key = { package = … }, | ||
// cargo-machete reports the unused spec properly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think this comment is a copy-pasto from the previous one, and should be updated maybe?
.expect("resolved dependency should have a matching dependency spec"); | ||
// If the dependency was renamed, through key = { package = … }, | ||
// the original key is in dep_spec.rename | ||
let dep_key = dep_spec.rename.clone().unwrap_or(dep_spec.name.clone()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: unwrap_or_else(|| dep_spec.name.clone())
to avoid the eager cloning of dep_spec.name
.metadata | ||
.as_ref() | ||
.and_then(|metadata| metadata.resolve.as_ref()) | ||
.filter(|metadata| metadata.resolve.is_some()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid the unwrap()
on the next line, we can probably zip the metadata along the resolve:
if let Some((metadata, resolve)) = analysis
.metadata
.as_ref()
.filter_map(|metadata| metadata.resolve.as_ref().and_then(|resolve| (metadata, resolve)) {
or something like that?
I'll address the comments to help with merging this. Thanks again! |
Hmm it seems I can't push to your fork, so I've opened #132. Thanks again! |
This makes cargo machete --with-metadata --fix work; it previously broke
with kebab-case package names and packages like xml-rs.
It also removes a hack that attempted to parse opaque source ids (last updated in #106).
The solution involves looking at .packages and not just .resolved.