feat: Stabilize Edition 2024 #14828
feat: Stabilize Edition 2024 #14828
Conversation
rustbot
added
A-documenting-cargo-itself
|
Posting this now to not lose track of the documentation update mentioned in #14754. |
| @@ -507,7 +507,7 @@ resolver = "2" | |||
| - `"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` | |||
| - `"3"` ([`edition = "2024"`](manifest.md#the-edition-field) default, requires Rust 1.84+): Change the default for [`resolver.incompatible-rust-versions`] from `allow` to `fallback` | |||
There was a problem hiding this comment.
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.lockfile 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.
There was a problem hiding this comment.
This was discussed in #14754 and the Cargo team still checked their boxes and didn't raise a concern to block FCP.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
|
@epage Is this ready to go once nightly is updated tomorrow? |
|
For what I know, yes |
|
@ehuss I realized I forgot to update the functions on |
|
Thanks! Unfortunately it looks like the latest nightly may have failed to publish. |
What does this PR try to resolve?
How should we test and review this PR?
Additional information