cargo update prints Adding + Removing lines when multiple versions of the same crate are updated

[Nemo157]

Problem
The more concise Updating lines are not printed if multiple versions of the same crate are updated in one command

Setup

> cargo new foo && cd foo
> echo 'bs58_02 = { package = "bs58", version = "0.2.0" }' >> Cargo.toml
> echo 'bs58_03 = { package = "bs58", version = "0.3.0" }' >> Cargo.toml
> cargo generate-lockfile
Updating crates.io index

> cargo update -p bs58:0.2.5 --precise 0.2.0
Updating crates.io index
Updating bs58 v0.2.5 -> v0.2.0

> cargo update -p bs58:0.3.1 --precise 0.3.0
Updating crates.io index
Updating bs58 v0.3.1 -> v0.3.0

Current

> cargo update
Updating crates.io index
Removing bs58 v0.2.0
Removing bs58 v0.3.0
Adding bs58 v0.2.5
Adding bs58 v0.3.1

Expectation

> cargo update
Updating crates.io index
Updating bs58 v0.2.0 -> v0.2.5
Updating bs58 v0.3.0 -> v0.3.1

Notes

Output of cargo version: cargo 1.53.0-nightly (65d57e6f3 2021-04-04)

[heisen-li]

@rustbot claim

[epage]

These messages are outputted by diffing the resolved dependency tree before and after.

We make the assumption that we can report Updated and Downgrading messages when there is just one added and one removed version of a package in the tree.

The challenge is knowing how to line up adds and removes when there are multiple versions of a package in the tree. Maybe we can make the assumption that, so long as they are semver compatible, that its an upgrade? I worry there are corner cases with that where version unification doesn't happen, like two git sources with different hashes, and would want further input from someone like @Eh2406 to know if there are a set of restrictions where this could be done and if there are any future plans that could further complicate it (like would we ever extend build-std's independent resolve graphs for other big projects like gitoxide or bevy and would that cause problems?).

[Eh2406]

This is a two-way dore. If this is not compatible with some other change we want to make we can back this out. The heuristic seems reasonable to me. (I am not remembering how GIT is handled in enough detail to know what exceptions need to be made there, but we can add a "and all versions are from a registry source" if needed.) It is also similar to Alex's suggestions in #9884

A bigger question is what happens to the message when cargo update is extended to semver breaking updates. And that is an area where you have more context then I.

[epage]

Agreed its a two way door. More so my concern is we are duplicating knowledge and either the hassle for tracking it or how acceptable we find "bugs" in this as we don't take this into account.

As for the breaking update, that would just not be subject to this (goes back to Adding and Removing) and we'd just tweak the algorithm more to cover more cases, if desired enough.