`cargo add` disables previously enabled features when converting between `_` and `-`

[Aloso]

Problem

cargo add can be used to add an optional feature to an existing dependency:

> cargo add once_cell -F unstable
    Updating crates.io index
      Adding once_cell v1.11.0 to dependencies.
             Features:
             + alloc
             + race
             + std
             + unstable
             - atomic-polyfill
             - parking_lot
             - parking_lot_core

> cargo add once_cell -F parking_lot
    Updating crates.io index
      Adding once_cell v1.11.0 to dependencies.
             Features:
             + alloc
             + parking_lot
             + parking_lot_core
             + race
             + std
             + unstable
             - atomic-polyfill
# note that `unstable` is still enabled from before!

Furthermore, cargo add can convert _ to - and vice versa in crate names. However, when doing this translation, existing features are dropped:

> cargo add once-cell -F parking_lot
    Updating crates.io index
warning: translating `once-cell` to `once_cell`
      Adding once_cell v1.11.0 to dependencies.
             Features:
             + alloc
             + parking_lot
             + parking_lot_core
             + race
             + std
             - atomic-polyfill
             - unstable
# note that `unstable` is no longer enabled!

cargo add should behave the same whether the crate name was written in its canonical form or not.

Version

cargo 1.63.0-nightly (a4c1cd0eb 2022-05-18)
release: 1.63.0-nightly
commit-hash: a4c1cd0eb6b18082a7e693f5a665548fe1534be4
commit-date: 2022-05-18
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1n)
os: Manjaro 21.2.6 (Qonos) [64-bit]

[epage]

What's happening is that the name as it exists on the command line was not found in the manifest, so we think its a new dependency and look it up in the registry. We do a fuzzy look up in the registry so that it will canonicalize it which causes it to match with an entry in the manifest and overwrites it.

Preferably we would not disable the canonicalization but extend it to checking existing dependencies. The code for this is currently embedded in the registry index code and would need to be pulled out to be reused.

We do not canonicalize git and path dependencies. It could be said that we should drop canonicalization completely to have parity between the code paths but it is less important for git / path dependencies because

• They will error if the name doesn't match
• The dependency name is optional, we will instead pull from the dependency's manifest.

[epage]

The part I'm a little uncertain of is if we allow fuzzy lookups into the manifest file

• Should we only allow that for registry dependencies or all dependencies?
• Should we prioritize the highest priority table or the closest match?

[epage]

#13702 is another manifestation of this