Tracking Issue for RFC 3085: Edition 2021

[Manishearth]

This is a tracking issue for the RFC "3085" (rust-lang/rfcs#3085).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

This is really a meta-tracker, since each individual edition feature tracked separately

The 2021 edition is tracked in https://github.com/orgs/rust-lang/projects/7

The edition change are:

1. Edition-specific preludes: Tracking issue for edition-specific preludes #85684
2. Cargo resolver = "2" default: Prepare Cargo for resolver = "2" as the default in the 2021 edition cargo#9048
3. IntoIterator for array with backwards compatibility hack: Tracking Issue for edition-dependent IntoIterator for arrays #84513
4. Disjoint capture in closures: https://github.com/rust-lang/project-rfc-2229/milestone/5
5. Panic macro consistency: Tracking Issue for RFC 3007: Making core and std's panic identical in Rust 2021 #80162
6. Reserved syntax: Tracking Issue for RFC 3101: Reserved Prefixes #84978
7. Promoting two warnings to hard errors: Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 #83213
8. Or patterns in macro_rules: Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e Foo(Bar(x) | Baz(x))" #54883

Unresolved Questions

• When should we use a migration and when should we prefer to be strictly backwards compatible?
  • This will roughly be decided on a per-feature basis
• What is the policy on warnings and lints tied to the edition?

[weiznich]

I want to officially raise my concern about making resolver = "2" default via a new edition. Note that the following statements are not about the general usefulness of resolver = "2" or what bugs are fixed by the new resolver, but only about if it is allowed to be changed as part of a new edition or not according to the relevant RFC. I fill this as comment here instead as new issue, as I believe that this does not belong into the tracking issue of resolver = "2", as it's about the inclusion into the new edition.

I believe that making the new feature resolver default via a edition boundary is contrary to RFC-2021. To cite from there what editions are allowed to change:

• Editions are never allowed to split the ecosystem. We only permit changes that still allow crates in different editions to interoperate.

RFC-2021

and

This ensures that the decision to migrate to a newer edition is a "private one" that the crate can make without affecting others, apart from the fact that it affects the version of rustc that is required, akin to making use of any new feature.

RFC-2021

At least in my understanding those points are not true for the resolver change, as this not only affects a single (leaf) crate of the compilation, but the whole dependency tree. This makes setting edition = "2021" in some crate affecting not only the crate opting into the now edition, but also all it's dependencies. This is contrary to the following statement from RFC-2021

Part of making edition migration easy is ensuring that users can choose when they wish to upgrade. We recognize that many users, particularly production users, will need to schedule time to manage an Edition upgrade as part of their overall development cycle.

as it may force the users providing said dependencies to update their edition as well. This may especially be true for popular crates that are widely used as dependency. Depending on there usage of proc macros, custom derives or their definition of minimal supported rust version + semver this may require major version bump and can result in degraded usability (as the user needs to pass additional matching feature flag to dependencies).

See related discussions in rust-lang/cargo#9450 and internals.rust-lang.org for real world examples and potential solutions. In both places it was promised that these concerns would be considered but at the same time neither the post at rust-lang.or nor this tracking issue indicates anything like that.

[m-ou-se]

@weiznich Yeah, the default resolver change is quite a different beast than the other edition changes, as it is outside the language. I don't think the problem you describe is a big one though, because having both edition = "2021" and resolver = "1" in your Cargo.toml is perfectly valid. In some way, it means both the Rust language and the cargo tool have different 'editions' now. And to keep things simple, one implies a default for the other. But they can be chosen independently from eachother.

Do we have any data or guesses on how many crates would not compile with resolver = "2"?

[weiznich]

@m-ou-se

I don't think the problem you describe is a big one though, because having both edition = "2021" and resolver = "1" in your Cargo.toml is perfectly valid. In some way, it means both the Rust language and the cargo tool have different 'editions' now. And to keep things simple, one implies a default for the other. But they can be chosen independently from eachother.

First of all rust-lang/cargo#9450 (comment) clearly states that cargo is covered by rusts stability guarantee. At least for me this implies that we cannot just say: "both the Rust language and the cargo tool have different 'editions' now" and hide that behind the a unified edition tag. That written: Yes, technically it's possible to "just revert" to the old resolver behaviour, but that misses my point. My main argument remains that this is a breaking change, not only for the current crate opting in the new edition (which would likely be fine), but for the whole dependency tree. There is no way for me as author of some crate in that dependency tree to have a choice about what some down stream user is specifying. Now I totally understand that this is a wanted change and so on, but technically that's not covered by the edition RFC. If you believe that's not the case I would like to know on which part of the RFC you base your argumentation on. I as author of a dependency crate do not have any free choice of the edition anymore, I need to make changes to keep my code compatible with both editions only to make it work for "downstream" users.

Let's use that example I personally care of: I'm one of diesels maintainers, which is considered as quite popular database interaction crate. As consequence it is used quite often. Diesel itself now does some things that are not quite compatible with edition = "2021" because of a split between a internal proc macro crate and the main crate. With the right combination of feature flags + resolver = "2" this will result into compilation errors, due to miss matching features. To fundamentally fix this rust needs to have some way to better couple proc macro crates and their parent crates together, which is currently not possible. There are various workarounds possible, but most of them would expose internal structure to our users or come with a lot of code churn. As consequence it is not easily possible to just make that crate out of the box compatible with resolver = "2". My fear with making resolver = "2" the default with the 2021 edition is now that this puts a quite large pressure on the maintainer team of popular crates like diesel, to somehow make the crate "compatible" with edition = "2021" (or so some people will claim).

That all written: I can clearly see why it would be desirable to change the default to the now resolver, but I would be happy if there was some more indication for potential users how to resolve issues coming from resolver ="1" vs resolver = "2" issues. rust-lang/cargo#9602 already provides some kind of fix for the diesel specific issue, but it would be great to have something more general as part of cargo fix. Maybe something like:

• If the compilation of some dependency fails, try again with resolver = "1"
• If that succeeds figure out the difference between both dependency trees feature wise and add the the missing features via direct dependencies.

Additionally all documentation and messaging around this feature should make it more than clear that any compilation error caused by this feature is not an issue in the crate cargo fails to compile, but an issue with the users configuration.

[Mark-Simulacrum]

Closing as this has stabilized and shipped.