-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(resolver): De-prioritize no-rust-version in MSRV resolver #13066
Conversation
This is a corner case without a good answer. As such, this change leans on some happy-path entries existing and preferring those.
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
r? @Eh2406 |
match (a.rust_version(), b.rust_version()) { | ||
// Fallback | ||
(None, None) => {} | ||
(Some(a), Some(b)) if a == b => {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be combined with the previous as (a, b) if a == b =>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiler doesn't recognize that None == None
and complains about the match
being non-exhaustive
@bors r+ |
☀️ Test successful - checks-actions |
Update cargo 25 commits in 26333c732095d207aa05932ce863d850fb309386..58fb23140972092a12f7011d17a7db1d99e3eacf 2023-11-28 20:07:39 +0000 to 2023-12-02 14:15:16 +0000 - test(install): use TCP connection instead of thread sleep (rust-lang/cargo#13099) - test(mdman): Switch to snapbox (rust-lang/cargo#13098) - Include declared list of features in fingerprint for `-Zcheck-cfg` (rust-lang/cargo#13012) - chore(deps): update compatible (rust-lang/cargo#13083) - chore(ci): Always update gix packages together (rust-lang/cargo#13093) - chore(deps): update rust crate windows-sys to 0.52 (rust-lang/cargo#13089) - refactor(toml): Decouple logic from schema (rust-lang/cargo#13080) - Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature (rust-lang/cargo#13071) - Add `--public` for `cargo add` (rust-lang/cargo#13046) - chore(deps): update rust crate toml_edit to 0.21.0 (rust-lang/cargo#13088) - chore(deps): update rust crate rusqlite to 0.30.0 (rust-lang/cargo#13087) - test(trim-paths): exercise with real world debugger (rust-lang/cargo#13091) - Fixed uninstall a running binary failed on Windows (rust-lang/cargo#13053) - chore(deps): update rust crate itertools to 0.12.0 (rust-lang/cargo#13086) - Add more options to registry test support. (rust-lang/cargo#13085) - Don't filter on workspace members when scraping doc examples (rust-lang/cargo#13077) - Remove the outdated comment (rust-lang/cargo#13076) - fix(resolver): Remove unused public-deps error handling (rust-lang/cargo#13036) - Fixes error count display is different when there's only one error left (rust-lang/cargo#12484) - fix: reorder `--remap-path-prefix` flags for `-Zbuild-std` (rust-lang/cargo#13065) - remove jobserver env var in some tests (rust-lang/cargo#13072) - doc: clarify different target has different set of `CARGO_CFG_*` values (rust-lang/cargo#13069) - docs: remove review capacity notice in PR template (rust-lang/cargo#13070) - chore(deps): update rust crate openssl to 0.10.60 [security] (rust-lang/cargo#13068) - fix(resolver): De-prioritize no-rust-version in MSRV resolver (rust-lang/cargo#13066) r? ghost
Update cargo 27 commits in 26333c732095d207aa05932ce863d850fb309386..623b788496b3e51dc2f9282373cf0f6971a229b5 2023-11-28 20:07:39 +0000 to 2023-12-02 18:10:03 +0000 - docs(book): make old title anchorable (rust-lang/cargo#13102) - Revert "chore(deps): update rust crate openssl to 0.10.60 [security]" (rust-lang/cargo#13101) - test(install): use TCP connection instead of thread sleep (rust-lang/cargo#13099) - test(mdman): Switch to snapbox (rust-lang/cargo#13098) - Include declared list of features in fingerprint for `-Zcheck-cfg` (rust-lang/cargo#13012) - chore(deps): update compatible (rust-lang/cargo#13083) - chore(ci): Always update gix packages together (rust-lang/cargo#13093) - chore(deps): update rust crate windows-sys to 0.52 (rust-lang/cargo#13089) - refactor(toml): Decouple logic from schema (rust-lang/cargo#13080) - Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature (rust-lang/cargo#13071) - Add `--public` for `cargo add` (rust-lang/cargo#13046) - chore(deps): update rust crate toml_edit to 0.21.0 (rust-lang/cargo#13088) - chore(deps): update rust crate rusqlite to 0.30.0 (rust-lang/cargo#13087) - test(trim-paths): exercise with real world debugger (rust-lang/cargo#13091) - Fixed uninstall a running binary failed on Windows (rust-lang/cargo#13053) - chore(deps): update rust crate itertools to 0.12.0 (rust-lang/cargo#13086) - Add more options to registry test support. (rust-lang/cargo#13085) - Don't filter on workspace members when scraping doc examples (rust-lang/cargo#13077) - Remove the outdated comment (rust-lang/cargo#13076) - fix(resolver): Remove unused public-deps error handling (rust-lang/cargo#13036) - Fixes error count display is different when there's only one error left (rust-lang/cargo#12484) - fix: reorder `--remap-path-prefix` flags for `-Zbuild-std` (rust-lang/cargo#13065) - remove jobserver env var in some tests (rust-lang/cargo#13072) - doc: clarify different target has different set of `CARGO_CFG_*` values (rust-lang/cargo#13069) - docs: remove review capacity notice in PR template (rust-lang/cargo#13070) - chore(deps): update rust crate openssl to 0.10.60 [security] (rust-lang/cargo#13068) - fix(resolver): De-prioritize no-rust-version in MSRV resolver (rust-lang/cargo#13066)
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>`.
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>`.
fix(resolver): Treat unset MSRV as compatible ### What does this PR try to resolve? Have the resolver treat no-MSRV as `rust-version = "*"`, like `cargo add` does for version-requirement selection ### How should we test and review this PR? We last tweaked this logic in #13066. However, we noticed this was inconsistent with `cargo add` in automatically selecting version requirements. It looks like this is a revert of #13066, taking us back to the behavior in #12950. In #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>`. See also #9930 (comment) r? `@Eh2406` ### Additional information
What does this PR try to resolve?
This is a corner case without a good answer.
As such, this change leans on some happy-path entries existing and
preferring those.
How should we test and review this PR?
Additional information
This was originally discussed around the time of #12950 but was held off.
When working on this, I was considering other heuristics like
--ignore-rust-version
, so I decided against these