feat: Stabilize MSRV-aware resolver config
What does this PR try to resolve?
This includes
-
cargo generate-lockfile --ignore-rust-version -
cargo update --ignore-rust-version
This does not include
-
edition = "2024" -
resolver = "3"
This is part of #9930
How should we test and review this PR?
Additional information
This is stacked on top of #14636. The commits for this PR start with the commit with a title that matches the PR title.
r? @ehuss
rustbot has assigned @ehuss. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Note: the final touches are not in place for this PR but I assume people can check their boxes based on the whole and assuming comments on this PR will get resolved.
I propose that we stabilize the MSRV-aware resolver.
- Offer an opt-in config for preferring MSRV-compatible packages over those that are incompatible, regardless of version
- Packages without an MSRV are always considered compatible
- If no MSRV is defined, fallback to the current toolchain's version
- Small tweaks in the algorithm are allowed as changes in the algorithm won't cause changes in lockfiles
- This only applies to local lockfile generation and not to
cargo install
This includes stabilizing
-
cargo generate-lockfile --ignore-rust-version -
cargo update --ignore-rust-version
This does not include stabilizing
-
edition = "2024" -
resolver = "3" - Features around the resolver that are meant to support MSRV workflows (e.g.
--update-rust-versionflag)
Deviations from the RFC
- Instead of the MSRV being the lowest among the workspace's MSRVs, we prioritze packages based on how many MSRVs from the workspace they are compatible with
- We only fallback to the current toolchain's version if no MSRV is set, rather than treating that as the MSRV for those packages
I had considered proposing we have this cover cargo install
- When viewed only as a config and keeping in mind that
cargo installonly reads from the user config (and so wouldn't be affected by the current repo's config), it sounds reasonable on the surface - However, people setting something in their config for
cargo installwould affect any repo that doesn't have its own config. Really,cargo installdoes need its own[install.resolver]table. - This also gets weirder when it comes to
resolver = "3"as we'd need to describe that as conditional
@rfcbot fcp merge
Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members:
- [x] @Eh2406
- [ ] @Muscraft
- [ ] @arlosi
- [x] @ehuss
- [x] @epage
- [x] @joshtriplett
- [x] @weihanglo
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
:umbrella: The latest upstream changes (presumably #14636) made this pull request unmergeable. Please resolve the merge conflicts.
:bell: This is now entering its final comment period, as per the review above. :bell:
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
@bors r+
The FCP has ended. To maximise the testing window I am going to merge this soon. Thank you all for your inputs!
:pushpin: Commit 498d4df89fbf6fc93329ce296fd82638e1504699 has been approved by weihanglo
It is now in the queue for this repository.
:hourglass: Testing commit 498d4df89fbf6fc93329ce296fd82638e1504699 with merge cf53cc54bb593b5ec3dc2be4b1702f50c36d24d5...
:sunny: Test successful - checks-actions Approved by: weihanglo Pushing cf53cc54bb593b5ec3dc2be4b1702f50c36d24d5 to master...