feat: Stabilize Edition 2024

[epage]

What does this PR try to resolve?

How should we test and review this PR?

Additional information

[rustbot]

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

[epage]

Posting this now to not lose track of the documentation update mentioned in #14754.

[weiznich]

I would like to point again to RFC-2052 especially to the hard constraints section there:

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

Given that this changes the resolver behavior you can end up in situations that result in broken builds if you specify a minimal supported rust version and a too broad minimal dependency version. That can then result in a changed version resolution to an dependency version which does not contain a public element that is used by the actual crate.

No warning about the possible broken build is emitted with the 2021 edition!

Ed Page pointed out before that this only happens if there is no Cargo.lock file as otherwise dependency resolution is not rerun on edition updates. Also he pointed out that this code is already faulty.

I argue again that neither arguments are valid here as:

• Projects without Cargo.lock file checked in git repositories where the default at the introduction of the 2021 edition, so cargo must expect that such projects still exists. After all these compile without warning on the latest cargo version
• A broken minimal dependency version only caused issues with unstable features (-Z minimal-version) in the past, not with any updates (at least as long as the dependency follows semver, but that's assumed as default). So this is a new built-error mode. (Or worded differently the rust compiler itself does also introduce warning periods for similar "fixes")

EDIT: To be clear here, I'm not calling for not stabilizing this feature, I'm just asking for adding the warning required by the RFC.

[epage]

This was discussed in #14754 and the Cargo team still checked their boxes and didn't raise a concern to block FCP.

[weiznich]

As far as I know the cargo team is responsible for managing cargo. The edition is a language feature, which means the cargo team is not the only responsible team to decide whether something violates the relevant RFC or not.

In addition to that above: Completing the FCP does not change fact that this violates that hard constraint as no such warning is emitted today. I would even argue that this might indicate that the cargo team knowingly decides to violate this RFC and therefore break the given stability guarantees (again).

[oli-obk]

Moderator note: both of you have stated everything there is to it from your perspectives. Further discussion between you two is not fruitful in my opinion. So other cargo team members can chime in, but I would like it if you two refrained from further commentary on this topic unless asked to by cargo team members.

[ehuss]

The Cargo team discussed these concerns, fully understands these concerns, and does not feel that a change is needed here. We do not think a warning could or should be provided here, due among other reasons to the high likelihood of false positives. We have been carefully considering the ecosystem impact of many different possible approaches to integrating MSRV into the dependency resolver, and we want to highlight that the experience of crate maintainers in many different circumstances has always been our foremost consideration.

[weiznich]

@ehuss I'm sorry to write that but your response does again not address the core of my concern. So let it me boil down to a simple question:

Which RCF or similar language level decision does exempt the cargo team from the following the rules outlined in RFC-2052?

Can you or a different team member answer this simple question instead of bringing up yet another iteration of excuses why this feature is important or why the given example is already broken.

[ehuss]

@epage Is this ready to go once nightly is updated tomorrow?

[epage]

For what I know, yes

[epage]

@ehuss I realized I forgot to update the functions on Edition. I then tried to update the tests as best as I could because of that. Likely missed stuff.

[ehuss]

Thanks! Unfortunately it looks like the latest nightly may have failed to publish.

[ehuss]

Thanks!