feat(resolver): Stabilize resolver v3

[epage]

What does this PR try to resolve?

This is a follow up to #14639 in prep for Edition 2024

How should we test and review this PR?

This is stacked on #14753

Additional information

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
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

[epage]

side note: When we stabilize 2024 edition, we'll need to update it to say that v3 is the default for it

[epage]

@rfcbot fcp merge

[rfcbot]

Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @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.

[weihanglo]

Implementation wise looks good.

[weiznich]

I would like to raise a concern about changing the default resolver at the edition boundary. In my reading of RFC-2052 that's something that is not covered by what editions are allowed to change.

Specifically this part of the RFC is relevant:

Sometimes a feature we want to make available in a new edition would require backwards-incompatible changes, like introducing a new keyword. In that case, the feature is only available by explicitly opting in to the new edition. Each crate can declare an edition in its Cargo.toml like edition = "2019"; otherwise it is assumed to have edition 2015, coinciding with Rust 1.0. Thus, new editions are opt in, and the dependencies of a crate may use older or newer editions than the crate itself.

Source, highlighting of the relevant section by me.

In my understanding that forbids any changes on how cargo resolves features, as by definition they affect the whole dependency tree, not only the crate that opt's into this changes. This suddenly turns supporting the new edition into something that is forced onto the dependency crates by the crate that opt's into the new edition.

And yes, I'm aware that the 2021 edition contained a similar change, I argued against that back then already for exactly the same reason.

[epage]

@weiznich package.resolver encompasses two resolvers, a dependency version resolver and a feature resolver. v3 only changes the dependency version resolver. The feature resolver remains unchanged. See https://rust-lang.github.io/rfcs/3537-msrv-resolver.html

EDIT: To add, this change will not affect existing lockfiles but only when the lockfile is already being changed (a changed Cargo.toml that causes a Cargo.lock change, cargo update, cargo generate-lockfile).

[weiznich]

package.resolver encompasses two resolvers, a dependency version resolver and a feature resolver. v3 only changes the dependency version resolver. The feature resolver remains unchanged. See https://rust-lang.github.io/rfcs/3537-msrv-resolver.html

Thanks for clarifying this difference. That's helpful. I believe that it is still possible that this might cause broken builds of dependencies, for example for the following cases:

• crate x declare a lower MSRV than any of its dependencies and the user tries to build with that minimal version as target
• crate x uses a wrong minimal version requirement for one of its dependencies and that gets resolved by the new MSRV constraint to an actual incompatible dependency crate version. (E.g writing serde = "1" but the actual requirement for a working build is serde = "1.0.100"

Crate x revers in both cases to an crate deep in the dependency tree of that crate that opts into the new resolver.

That's written: I would consider both cases above to be clear bugs in crate x and I cannot come up with other examples, so I suppose this might be fine. Therefore consider my concern here resolved.

EDIT: To add, this change will not affect existing lockfiles but only when the lockfile is already being changed (a changed Cargo.toml that causes a Cargo.lock change, cargo update, cargo generate-lockfile).

That's from my point of view not relevant, as it will nevertheless opt in dependencies into the new resolver behaviour by using any of these commands, which might be seen as direct violation of the cited part of the edition RFC.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔