fix(resolver): Treat unset MSRV as compatible by epage · Pull Request #13791 · rust-lang/cargo

@epage

We last tweaked this logic in rust-lang#13066.
However, we noticed this was inconsistent with `cargo add` in
automatically selecting version requirements.

It looks like this is a revert of rust-lang#13066, taking us back to the behavior
in rust-lang#12950.
In rust-lang#12950 there was a concern about the proliferation of no-MSRV and
whether we should de-prioritize those to make the chance of success more
likely.

There are no right answes here, only which wrong answer is ok enough.
- Do we treat lack of rust version as `rust-version = "*"` as some
  people expect or do we try to be smart?
- If a user adds or removes `rust-version`, how should that affect the
  priority?

One piece of new information is that the RFC for this has us trying to
fill the no-MSRV gap with
`rust-version = some-value-representing-the-current-toolchain>`.

This was referenced

Apr 23, 2024

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

May 1, 2024

@epage epage deleted the msrv-unset branch

May 2, 2024 00:07

bors added a commit to rust-lang-ci/rust that referenced this pull request

May 3, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request

May 4, 2024

flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request

May 24, 2024