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. 🔔

[weiznich]

I would like to add another question here: The edition RFC states as hard constraint:

TL;DR: Warning-free code on edition N must compile on edition N+1 and have the same behavior.

Does cargo warn for cases that might be broken by this change? See my previous case for examples of potential broken builds.

[epage]

When a user migrates from 2021 to 2024 edition, there code will still work as it does today. The new resolver behavior will still respect their lockfile and not force the dependencies to match the MSRV.

If they take an explicit action, like adding a new dependency or running cargo generate-lockfile, then that opens them up to "whatever state the index is in" combined with "the resolver policy". I would consider that outside of the scope of what editions specify.

If someone does not commit their lockfile (which we've made committing the default behavior), then they don't need to perform an explicit action but they are still open to "whatever state the index is in" combined with "the resolver policy". I would still consider that to be outside of the scope of Editions.

[weiznich]

When a user migrates from 2021 to 2024 edition, there code will still work as it does today. The new resolver behavior will still respect their lockfile and not force the dependencies to match the MSRV.

If they take an explicit action, like adding a new dependency or running cargo generate-lockfile, then that opens them up to "whatever state the index is in" combined with "the resolver policy". I would consider that outside of the scope of what editions specify.

That's a good argument, as long as it needs an additional step that's fine.

If someone does not commit their lockfile (which we've made committing the default behavior), then they don't need to perform an explicit action but they are still open to "whatever state the index is in" combined with "the resolver policy". I would still consider that to be outside of the scope of Editions.

I think that's not the correct conclusion here. Yes you changed the default, but old projects still exists and these guarantees applies to them as well. Otherwise you would just declare any old project outside the scope of editions, which is really strange. The easy way to workaround this without spending much time on implementing warnings for this change would be to warn for not-existing lock files on edition updates.

[rfcbot]

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.

[weihanglo]

In terms of the hypothetical example in #14754 (comment), and the "Warning-free code on edition N must compile on edition N+1 and have the same behavior" statement, they happens more often nowadays without MSRV-aware resolver. If a package doesn't commmit its lockfile, it may break one way or the other becase MSRV bump may happen within SemVer minor range.

I think what you've described is actually the area the resolver v3 tries to make it a bit smoother. Resolver V3 is not silver bullent eliminating every corner cases, though it does minimize chances of those happening. Hence, I agree with Ed that the not-commiting-lockfiles case is kinda out-of-scope.

---

BTW I would encourage people to use inline (threaded) comments for discussions, see rust-lang/rfcs#3717.

[weihanglo]

The FCP is complete. Thank you all for your participation!

[weiznich]

@weihanglo I'm not sure how that is related to the warning free code argument. Sure that old code can break also in different ways but that's often the case. And yes I agree with you that all the provided examples that fail to compile with the new resolver are essentially broken in some way. Nevertheless they compile without warning using the current edition.

The relevant point here is that you are adding a new way to break things and that you make that new way the default with the new addition. This on its own is fine as long as you follow the rules of such edition changes. These rules are in my opinion clear as they literally say warning free code on edition N-1 must compile on edition N! I'm not aware of any exception from this rule. Given that I do not even understand why you even try to argue about that: Either you want to change the default with the edition then you must follow these rules (or submit an RFC with new rules) or you cannot change the default. My suggestion would be to warn for crates that don't include their lock files in their vcs, which should be reasonably easy to do and would sidestep the problem as explained by Ed Page above.

And to be sure: I will continue to argue about that and possibly involve an wider audience.

[ehuss]

Re-queued, for some reason fix::migrate_rename_underscore_fields hung.