Fix for "Running cargo update without a Cargo.lock ignores arguments" #6872

[fluffysquirrels]

No description provided.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[fluffysquirrels]

Closes #6872.

[alexcrichton]

Oops sorry I missed this! Could this perhaps be structured a way internally that doesn't involve recursing and redoing a lot of work? Perhaps the branch could simply return an empty resolve as the previous resolve since one technically doesn't exist?

[fluffysquirrels]

I can see how to remove the recursion and skip saving and reloading Cargo.lock.

The current code queries previous_resolve (loaded from the Cargo.lock), looking for the dependencies' PackageId to do the update. I'll try and work out another way to query this, it looks like PackageRegistry might work.

[fluffysquirrels]

This updated code avoids recursion and an unnecessary save and load of the lock file.

The second new PackageRegistry is required to avoid a failed assertion assert!(!self.patches_locked) in PackageRegistry::lock_patches.

To avoid using a first resolve_with_previous at all, I'm looking to use PackageRegistry::query (provides a set of Summary structs) to replace Resolve::query (returns a single PackageId struct) in the update logic. I'm not sure how I'd go about finding a unique PackageId from this set. I can filter by the version string provided to update on the command line, but it's not clear to me that will provide a unique answer.

[alexcrichton]

Hm so if you update this branch to simply return an empty Resolve (aka Resolve::default(), adding that if it doesn't already exist), I think that would also pass tests and exhibit the desired behavior?

[fluffysquirrels]

There is no Resolve::default()currently, and if I wrote a trivial one with e.g. an empty .graph field, then Resolve::query() would just query the empty graph and return nothing, hence in cargo update we wouldn't find any of the dependencies we were trying to update.

I can pass None instead of Some(resolve) to ops::resolve_with_previous later in cargo update, but then I still need SourceIds for each package we are updating, and I don't know how to get them.

[alexcrichton]

Oh I think I see. I thought that the --precise information was carried through some other side channel that didn't require the previous resolve, but I see now how it needs the previous resolve. This feels pretty bad but that's not your fault at all, it's largely just how badly designed the method of passing --precise down is! (blame me for that)

In light of that this looks good to me!

@bors: r+

[bors]

📌 Commit 36160ed has been approved by alexcrichton

[bors]

⌛ Testing commit 36160ed with merge 1b4fab3...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 1b4fab3 to master...