feat(resolver): Stabilize resolver v3 by epage · Pull Request #14754 · rust-lang/cargo (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

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

Comment on lines 507 to +510

- `"2"` ([`edition = "2021"`](manifest.md#the-edition-field) default): Introduces changes in [feature
unification](#features). See the [features chapter][features-2] for more
details.
- `"3"` (requires Rust 1.84+): Change the default for [`resolver.incompatible-rust-versions`] from `allow` to `fallback`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@epage

@rfcbot

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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@epage

@epage epage mentioned this pull request

Nov 7, 2024

27 tasks

@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

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

@epage epage mentioned this pull request

Nov 15, 2024

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

Nov 16, 2024

@bors

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

Nov 16, 2024

@bors

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

Nov 17, 2024

@bors

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request

Jan 22, 2025

@tmeijn

This MR contains the following updates:

Package Update Change
rust minor 1.83.0 -> 1.84.0

MR created with the help of el-capitano/tools/renovate-bot.

Proposed changes to behavior should be submitted there as MRs.

Release Notes

rust-lang/rust (rust)

v1.84.0

Compare Source

==========================

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts

Cargo

Rustdoc

Compatibility Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

This MR has been generated by Renovate Bot.

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Feb 2, 2025

@he32

Pkgsrc changes:

Upstream changes:

Version 1.84.1 (2025-01-30)

Version 1.84.0 (2025-01-09)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts

Cargo

Rustdoc

Compatibility Notes