-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Conversation
This comment has been minimized.
This comment has been minimized.
6fcd0f2
to
2a9e6c5
Compare
This comment has been minimized.
This comment has been minimized.
2a9e6c5
to
63d06b2
Compare
This comment has been minimized.
This comment has been minimized.
b32107f
to
dc9c8d5
Compare
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? |
There was a problem hiding this 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.
@@ -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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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) |
There was a problem hiding this comment.
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?
This is a nice side effect, the actual reason being the bootstrap process: To build the #[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. |
auto trait
syntax in favor of new attribute #[rustc_auto_trait]
auto trait
syntax in favor of new attribute #[rustc_auto_trait]
dc9c8d5
to
855e006
Compare
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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^^
This comment has been minimized.
This comment has been minimized.
855e006
to
81cd7b7
Compare
i.span, | ||
"auto traits are experimental and possibly buggy" | ||
); | ||
// FIXME: Consider using a structured suggestion. |
There was a problem hiding this comment.
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)] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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]
.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed
There was a problem hiding this 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)]`")), |
There was a problem hiding this comment.
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` |
There was a problem hiding this comment.
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?
tests/ui/macros/stringify.rs
Outdated
assert_eq!( | ||
stringify_item!( | ||
pub unsafe auto trait Send {} | ||
pub unsafe trait Send {} | ||
), | ||
"pub unsafe auto trait Send {}", | ||
"pub unsafe trait Send {}", | ||
); |
There was a problem hiding this comment.
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 {} |
There was a problem hiding this comment.
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?
81cd7b7
to
c1a8109
Compare
c1a8109
to
21edda7
Compare
Nominating this for T-lang discussion. If it's possible and if I can make it, I will attend the meeting. |
☔ The latest upstream changes (presumably #116376) made this pull request unmergeable. Please resolve the merge conflicts. |
21edda7
to
ef3695d
Compare
This comment has been minimized.
This comment has been minimized.
ef3695d
to
c962db9
Compare
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 |
this is a nightly feature? why are we concerned about breakage like that? |
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. |
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 🙏. |
Zulip topic that kicked this off.
auto trait
but reject it after macro expansion#[rustc_auto_trait]
as a replacement forauto trait
auto_traits
in favor of the internal featurerustc_attrs
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