Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for RFC 3085: Edition 2021 #85811

Closed
2 tasks
Manishearth opened this issue May 29, 2021 · 4 comments
Closed
2 tasks

Tracking Issue for RFC 3085: Edition 2021 #85811

Manishearth opened this issue May 29, 2021 · 4 comments
Labels
A-edition-2021 Area: The 2021 edition B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-core Relevant to the core team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

Manishearth commented May 29, 2021

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?
@Manishearth Manishearth added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-core Relevant to the core team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels May 29, 2021
@jonas-schievink jonas-schievink added the A-edition-2021 Area: The 2021 edition label May 29, 2021
@weiznich
Copy link
Contributor

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.

@wesleywiser wesleywiser added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Jun 2, 2021
@m-ou-se
Copy link
Member

m-ou-se commented Jul 5, 2021

@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
Copy link
Contributor

weiznich commented Jul 6, 2021

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

@crlf0710 crlf0710 mentioned this issue Aug 16, 2021
11 tasks
@Mark-Simulacrum
Copy link
Member

Closing as this has stabilized and shipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2021 Area: The 2021 edition B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-core Relevant to the core team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants