Confusing error 'no matching package' on bad version

[Wilfred]

Problem

When given an invalid version for a package that exists, Cargo produces the following error:

error: no matching package named `rayon` found

This is confusing, as it makes it sound like the package name is incorrect, rather than the version.

Steps

$ cargo new cargo-15015 && cd cargo-15015 && cargo add rayon && cargo update -p rayon --precise 1.13.0
    Creating binary (application) package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
    Updating crates.io index
      Adding rayon v1.10.0 to dependencies
             Features:
             - web_spin_lock
    Updating crates.io index
     Locking 6 packages to latest compatible versions
    Updating crates.io index
error: no matching package named `rayon` found
location searched: registry `crates-io`
required by package `foo v0.1.0 (/home/wilfred/tmp/foo)`

Possible Solution(s)

The error message would ideally mention the package version being a problem.

Version

$ cargo --version                       
cargo 1.83.0 (5ffbef321 2024-10-29)

[weihanglo]

Thanks for the bug report!

We've improved the version with rejected reason in #14927 like this:

[UPDATING] `dummy-registry` index
[ERROR] failed to select a version for the requirement `foo = "^0.1.1"`
  version 0.1.3 requires cargo 1.2345
  version 0.1.4 requires a Cargo version that supports index version 1000000000
  version 0.1.5's index entry is invalid
  version 0.1.6 requires a Cargo version that supports index version 1000000000
  version 0.1.7's index entry is invalid
location searched: `dummy-registry` index (which is replacing registry `crates-io`)

However, for --precise usage, Cargo kinda locks the dependency requirement to the precise version before handling it over to the dependency resolver. As a result, when the resolver tries to provide more error contexts by querying again with wildcard * requirement, it then suffers from the same aforementioned "locking to the precise version" logic, getting no candidate at all.

It might be helpful if we have a new QueryKind variant, so the RegistrySource can decide whether to call precise_to or not.

[epage]

imo QueryKind::RejectedVersions would likely match the idea in this of getting all.

[weihanglo]

They are perhaps two approaches.

• Don't lock to precise When query kind is RejectedVersions This may not work because we'll lose the precise version information, which may turn into a bad error messages.
• Add a new OptVersionReq::matches_original method, which matches version with the original req not the locked/precise'd req. And when query kind is RejectedVersions, use it instead.

I am not sure which is preferred and has a long-term benefit.