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

Prepare removal of auto trait syntax in favor of new attribute #[rustc_auto_trait] #116126

Closed

Conversation

fmease
Copy link
Member

@fmease fmease commented Sep 24, 2023

Zulip topic that kicked this off.

  • Continue to parse auto trait but reject it after macro expansion
    • Necessary for bootstrapping
    • Should lessen ecosystem impact (assuming third-party crates gate auto traits behind a Cargo feature flag)
    • Full removal of the syntax can happen earliest after the next beta bump that occurs once this PR has been merged
  • Introduce the internal attribute #[rustc_auto_trait] as a replacement for auto trait
  • Remove the feature auto_traits in favor of the internal feature rustc_attrs
  • Update the world

It's unclear if this PR is blocked on an RFC due to backward compatibility concerns and due to potential ecosystem churn as potentially several third-party libraries have started to rely on this unstable but essentially internal feature.
Investigations needed (e.g., crater run). Reportedly, pyo3 relies on auto traits behind a Cargo feature flag.

r? @ghost

@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Sep 24, 2023
@fmease fmease added T-lang Relevant to the language team, which will review and decide on the PR/issue. S-blocked Status: Blocked on something else such as an RFC or other implementation work. F-auto_traits `#![feature(auto_traits)]` and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 24, 2023
@rust-log-analyzer

This comment has been minimized.

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from 6fcd0f2 to 2a9e6c5 Compare September 24, 2023 23:27
@rust-log-analyzer

This comment has been minimized.

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from 2a9e6c5 to 63d06b2 Compare September 24, 2023 23:53
@rust-log-analyzer

This comment has been minimized.

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch 2 times, most recently from b32107f to dc9c8d5 Compare September 25, 2023 01:24
@Noratrieb
Copy link
Member

I don't think we need an RFC to change the syntax. Libraries that use this know what they're doing and can live with it.

Additionally, can you remove the is_auto from the AST?

Copy link
Member

@Noratrieb Noratrieb left a comment

Choose a reason for hiding this comment

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

I see, it's still in the AST to emit an error, makes sense. Ideally we can remove that too at some point but for now it's fine.

I don't think we should bother cratering this and fixing people's code. The error message is pretty clear so people should know what to do and it's a nightly feature that was always pretty experimental unlike say, box syntax. But even for box syntax we didn't care about fixing anyone.

compiler/rustc_ast/src/ast.rs Show resolved Hide resolved
@@ -551,6 +551,10 @@ pub const BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[
may_dangle, Normal, template!(Word), WarnFollowing, dropck_eyepatch,
"`may_dangle` has unstable semantics and may be removed in the future",
),
gated!(
rustc_auto_trait, Normal, template!(Word), WarnFollowing, auto_traits,
Copy link
Member

Choose a reason for hiding this comment

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

This should already be gated with rustc_attrs, I don't see the point in having an extra gate. It should be moved to the other rustc attrs.

Copy link
Member Author

Choose a reason for hiding this comment

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

+1 on removing auto_traits and making #[rustc_auto_trait] part of rustc_attrs. I didn't do that since people in the Zulip topic were proposing marking auto_traits internal instead of removing it.

compiler/rustc_hir/src/hir.rs Show resolved Hide resolved
hir::ItemKind::Trait(is_auto, unsafety, .., items) => {
(is_auto == hir::IsAuto::Yes, unsafety, items)
hir::ItemKind::Trait(unsafety, .., items) => {
(tcx.has_attr(def_id, sym::rustc_auto_trait), unsafety, items)
Copy link
Member

Choose a reason for hiding this comment

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

could you move the auto check next to the conductive check?

@fmease
Copy link
Member Author

fmease commented Sep 25, 2023

Additionally, can you remove the is_auto from the AST?

I see, it's still in the AST to emit an error, makes sense. Ideally we can remove that too at some point but for now it's fine.

This is a nice side effect, the actual reason being the bootstrap process: To build the stage1 compiler artifacts, the beta compiler compiles core (etc.) beforehand. Therefore we can't remove the syntax just yet (and modify the parser and AST), not until the next beta bump that occurs after this PR has been merged. You can see my heavy use of cfg(bootstrap) in library/ and compiler/rustc_data_structures/ of the form:

#[cfg(bootstrap)]
auto trait Trait {}

#[cfg(not(bootstrap))]
#[rustc_auto_trait]
trait Trait {}

Initially I planned on opening two PRs simultaneously, this one and one that updates the parser and the AST (blocked on beta bump) but since I wasn't sure how long the grace period should be and if this PR here gets accepted at all, I didn't go through with it in the end.

@fmease fmease changed the title [blocked] Prepare removal of auto trait syntax in favor of new attribute #[rustc_auto_trait] Prepare removal of auto trait syntax in favor of new attribute #[rustc_auto_trait] Sep 25, 2023
@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from dc9c8d5 to 855e006 Compare September 27, 2023 12:50
Copy link
Member Author

@fmease fmease Sep 27, 2023

Choose a reason for hiding this comment

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

It's a shame that this beautifully written chapter has to be removed. I figure the contents could be moved to the rustc dev guide?

Copy link
Member

Choose a reason for hiding this comment

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

it definitely shouldn't be deleted from reality^^

@rust-log-analyzer

This comment has been minimized.

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from 855e006 to 81cd7b7 Compare September 27, 2023 13:24
i.span,
"auto traits are experimental and possibly buggy"
);
// FIXME: Consider using a structured suggestion.
Copy link
Member

Choose a reason for hiding this comment

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

not having one is fine imo, but you can add one if you want to

or enum type.

Erroneous code example:

```compile_fail,E0321
#![feature(auto_traits)]
Copy link
Member

Choose a reason for hiding this comment

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

should this use negative_impls?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess I can add it but it doesn't seem mandatory. Apparently, stderr is allowed to contain more errors than listed after compile_fail. Several other error code code blocks also lack #![feature].

Copy link
Member

Choose a reason for hiding this comment

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

yeah, it doesn't seem mandatory but it's nice to have it

Copy link
Member Author

Choose a reason for hiding this comment

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

Addressed

Copy link
Member

@Noratrieb Noratrieb left a comment

Choose a reason for hiding this comment

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

I took a closer look and have a few more comments. But the more I look at it, the more I like it, I think this is a great change.

@@ -50,6 +50,9 @@ declare_features! (
(removed, allocator, "1.0.0", None, None, None),
/// Allows a test to fail without failing the whole suite.
(removed, allow_fail, "1.19.0", Some(46488), None, Some("removed due to no clear use cases")),
/// Allows features specific to auto traits.
/// Renamed from `optin_builtin_traits`.
(removed, auto_traits, "1.50.0", Some(13231), None, Some("removed in favor of `#[feature(rustc_attrs)]`")),
Copy link
Member

Choose a reason for hiding this comment

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

instead of the features, can you show the attribute directly here?

@@ -1,106 +0,0 @@
# `auto_traits`
Copy link
Member

Choose a reason for hiding this comment

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

leaving a comment here to remember to copy these docs to somewhere else. maybe we should have a subdirectory about rustc_attrs in the unstable book?

src/librustdoc/clean/mod.rs Show resolved Hide resolved
Comment on lines 570 to 575
assert_eq!(
stringify_item!(
pub unsafe auto trait Send {}
pub unsafe trait Send {}
),
"pub unsafe auto trait Send {}",
"pub unsafe trait Send {}",
);
Copy link
Member

Choose a reason for hiding this comment

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

can you make the one below pub and delete this assert?

@@ -0,0 +1,14 @@
trait Trait1 {}
Copy link
Member

Choose a reason for hiding this comment

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

can you make this a revision test to make this fully independent of recovery, making sure that it passes for the #[cfg(not_enabled)] case?

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from c1a8109 to 21edda7 Compare September 29, 2023 14:31
@fmease
Copy link
Member Author

fmease commented Sep 29, 2023

Nominating this for T-lang discussion. If it's possible and if I can make it, I will attend the meeting.
The details on this change (motivation, drawbacks, etc.) can be found here:
https://hackmd.io/@fmease/rustc_auto_trait (Zulip topic).

@fmease fmease added the I-lang-nominated Nominated for discussion during a lang team meeting. label Sep 29, 2023
@bors
Copy link
Contributor

bors commented Oct 3, 2023

☔ The latest upstream changes (presumably #116376) made this pull request unmergeable. Please resolve the merge conflicts.

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from 21edda7 to ef3695d Compare October 3, 2023 17:26
@rust-log-analyzer

This comment has been minimized.

@fmease fmease force-pushed the prep-auto-trait-syntax-removal branch from ef3695d to c962db9 Compare October 3, 2023 17:38
@fmease
Copy link
Member Author

fmease commented Oct 3, 2023

Closing as per T-lang meeting 2023-10-03.

The breakage is not worth it given the number of large crates using it like PyO3. It's even unclear if auto_traits should be marked internal after all. Unmaintained could be a better category. We might want to reuse the current auto trait syntax but change the semantics at some point to be less footgun-y.

@fmease fmease closed this Oct 3, 2023
@fmease fmease deleted the prep-auto-trait-syntax-removal branch October 3, 2023 20:39
@fmease fmease removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Oct 3, 2023
@Noratrieb
Copy link
Member

this is a nightly feature? why are we concerned about breakage like that?

@Noratrieb
Copy link
Member

I see, it's mostly about the valid use cases: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Removal.20of.20.60auto.20trait.60.20syntax

That's understandable.

@fmease
Copy link
Member Author

fmease commented Oct 6, 2023

Right, sorry that that wasn't clear. I wrote that summary right after the meeting without checking if it made any sense.

Personally speaking I'm still an opponent of auto traits as currently designed and implemented. I can see how vital they are for modelling certain things and that they find great use in well-known crates but I wish the feature would be more constrained and controlled.

Thanks for the reviews on this PR, @Nilstrieb, regardless of the final outcome 🙏.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustdoc-json Area: Rustdoc JSON backend F-auto_traits `#![feature(auto_traits)]` S-blocked Status: Blocked on something else such as an RFC or other implementation work. T-compiler Relevant to the compiler 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 Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants