Skip to content

RFC: Deprecate the per-build-target edition field in Cargo.toml #3772

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

Merged
merged 6 commits into from
Mar 8, 2025

Conversation

epage
Copy link
Contributor

@epage epage commented Feb 13, 2025

Deprecate lib.edition, etc in favor of only setting package.edition, removing the fields in the next Edition.

Rendered

@epage epage added the T-cargo Relevant to the Cargo team, which will review and decide on the RFC. label Feb 13, 2025
@clarfonthey

This comment was marked as duplicate.

@Lokathor

This comment was marked as duplicate.

- doctests
- creating packages just for the sake of defining tests

# Rationale and alternatives
Copy link
Contributor Author

@epage epage Feb 14, 2025

Choose a reason for hiding this comment

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

@clarfonthey from #3772 (comment)

I didn't even know this was an option, and I agree it's very confusing, especially considering how cargo itself is affected by editions.

I honestly would go further and propose working with the existing crates that use this feature to remove it, then disabling it for all editions in a future version. Making the presence of an edition field depend on edition feels weird.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This seems to run counter to our compatibility guarantees. We take this approach to help people as we fix bugs that people accidentally relied on but this was intentional behavior supported in the manifest and documented as part of working with Editions. In practice, this would mean that new versions of cargo would not be able to build older versions of crates like linkme, nameof, and num-derive.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added d8c992a which discusses one edition field affecting another

Choose a reason for hiding this comment

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

That's very fair, and I guess my justification comes from the fact that the feature is extremely counter-intuitive and not used very often. However, from what you've mentioned, it is used a lot in the ecosystem, just not in very many crates, which means that at least half of my argument is invalid.

So, it's fair to prefer this over an edition boundary rather than removing it outright.

A non-`None` edition will be considered deprecated
- A deprecation message will eventually be shown by Cargo
- Timing depends on if this will be blocked on having `[lints]` control over this or not
- In Edition 20XX+, an error will be reported when this field is present
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Lokathor from #3772 (comment)

So the error case is if you set an edition >= X in your package and then also set any edition value at all in particular build targets?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. I will make that more clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See 13702bb

@joshtriplett
Copy link
Member

@rfcbot merge

@rfcbot
Copy link
Collaborator

rfcbot commented Feb 17, 2025

Team member @joshtriplett 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.

@rfcbot rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Feb 17, 2025
@ehuss
Copy link
Contributor

ehuss commented Feb 25, 2025

I'm checking my box, though I do note that cross-edition testing, particularly of macros, can be challenging. However, it seems evident that it is extremely rare that anyone is doing that, and there are workarounds (such as using separate test packages), and the benefits seem to outweigh that drawback to me.

@rfcbot rfcbot added the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Feb 26, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Feb 26, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Feb 26, 2025
Copy link
Member

@0xPoe 0xPoe left a comment

Choose a reason for hiding this comment

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

Thanks!

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Mar 8, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Mar 8, 2025

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.

@ehuss
Copy link
Contributor

ehuss commented Mar 8, 2025

The @rust-lang/cargo team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here: rust-lang/cargo#15283

@ehuss ehuss merged commit 2defc68 into rust-lang:master Mar 8, 2025
@epage epage deleted the build-target-edition branch March 8, 2025 21:16
epage added a commit to epage/cargo that referenced this pull request Mar 10, 2025
Leaving off any talk of it being removed until we know the edition.

This is the first step in implementing rust-lang/rfcs#3772 (tracking issue rust-lang#15283)
epage added a commit to epage/cargo that referenced this pull request Mar 11, 2025
Leaving off any talk of it being removed until we know the edition.

This is the first step in implementing rust-lang/rfcs#3772 (tracking issue rust-lang#15283)
github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Mar 11, 2025
### What does this PR try to resolve?

This is the first step in implementing rust-lang/rfcs#3772 (tracking
issue #15283)

### How should we test and review this PR?

Leaving off any talk of it being removed until we know the edition.

### Additional information
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-cargo Relevant to the Cargo team, which will review and decide on the RFC. to-announce
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

7 participants