Skip to content
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

Closed
wants to merge 3 commits into from
Closed

Rewrite cargo-metadata support #122

wants to merge 3 commits into from

Conversation

g2p
Copy link
Contributor

@g2p g2p commented May 27, 2024

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.

@g2p g2p force-pushed the cargo-metadata branch 3 times, most recently from a21f5cf to 9086b57 Compare May 27, 2024 20:00
g2p added 3 commits May 27, 2024 22:01
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.
@g2p g2p force-pushed the cargo-metadata branch from 9086b57 to 95b3e27 Compare May 27, 2024 20:02
@DenisGorbachev
Copy link

Experienced this bug too, hope that this pull request fixes is

Copy link
Owner

@bnjbvr bnjbvr left a 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.

Comment on lines +802 to +803
// when a lib is renamed through key = { package = … },
// cargo-machete reports the unused spec properly.
Copy link
Owner

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());
Copy link
Owner

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())
Copy link
Owner

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?

@bnjbvr
Copy link
Owner

bnjbvr commented Aug 23, 2024

I'll address the comments to help with merging this. Thanks again!

@bnjbvr
Copy link
Owner

bnjbvr commented Aug 23, 2024

Hmm it seems I can't push to your fork, so I've opened #132. Thanks again!

@bnjbvr bnjbvr closed this Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants