-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
[Syntax] Implement auto trait syntax #45247
Conversation
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
917cb34
to
90c80f1
Compare
Some code are still using the old names.
|
@kennytm Thanks, fixed it! |
We could remove it ASAP, but it may be kind to offer a grace period. In the compiler itself, we can just use |
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.
What do you think about simplifying the HIR representation to align better with the new syntax? Would you need some tips for how to work that through?
Also, we may want to start issuing a future compatibility warning if we are going to continue to accept the old syntax.
let has_default_impl = tcx.hir.trait_is_auto(def_id); | ||
let is_auto = match item.node { | ||
hir::ItemTrait(hir::IsAuto::Yes, ..) => true, | ||
_ => tcx.hir.trait_is_auto(def_id), |
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.
Once we make hir::IsAuto::Yes
be the canonical way to encode hir traits, this code can be simplified, as can quite a bit of other code I imagine.
@@ -1479,14 +1479,14 @@ impl<'a> LoweringContext<'a> { | |||
let vdata = self.lower_variant_data(vdata); | |||
hir::ItemUnion(vdata, self.lower_generics(generics)) | |||
} | |||
ItemKind::DefaultImpl(unsafety, ref trait_ref) => { | |||
ItemKind::AutoImpl(unsafety, ref trait_ref) => { |
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'd prefer to see all evidence of impl Trait for ..
go away by the time HIR lowering is done. That is, I think the HIR should not include impl Trait for ..
-style impls, and instead we should lower any trait that contains such an impl to have hir::IsAuto
set to true.
This will presumably require one of two things:
- A pre-pass that identifies the set of traits targeted by auto-impls, so that later, when we lower traits, we can set
hir::IsAuto
to true. - Or, alternatively, we could collect the set as we walk, and update the lowered form of traits after the fact. I suspect we still have unique access and can mutate them in place?
That said, I'm not convinced this is a widely used feature. At least I sort of hope it's not. So maybe it's better to just make the change immediately. |
Probably worth testing. =) |
To work around the limitations of #[cfg(stage0)]
macro_rules! conditional {
(stage0 => { $($stage0:tt)* } stageN => { $($stageN:tt)* }) => $($stage0)*
}
#[cfg(not(stage0))]
macro_rules! conditional {
(stage0 => { $($stage0:tt)* } stageN => { $($stageN:tt)* }) => $($stageN)*
} now you can do: conditional {
stage0 => {
trait Foo { }
impl trait Foo for .. { }
}
stageN => {
auto trait Foo { }
}
} but even better might be to make: auto_trait!(Foo); that expands to either |
@nikomatsakis Thanks, I'll work on killing off the old syntax then! |
@rfcbot fcp merge This PR changes the syntax of auto traits to be This FCP is specifically for making the shift, but not for stabilization (of course) of any part of auto traits that are not already stabilized. |
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, 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. |
I'm not sold on the syntax but if we can't come up with anything more interesting/descriptive 🤷♂️ |
@rfcbot reviewed |
If we kill the old syntax now by abusing Since we must accept the old syntax for a few more weeks, I think an error level future compatibility lint would be appropiate. In January there were 15 users of this feature in crates.io.
Coherence needs to check orphan rules, overlap and unsafety for |
☔ The latest upstream changes (presumably #45175) made this pull request unmergeable. Please resolve the merge conflicts. |
04f4c4e
to
7dc5d57
Compare
Now we can do the well formedness checks in the parser, yay!
Forgot this ones.
This moves the well formedness checks to the AST validation pass. Tests were adjusted. The auto keyword should be back-compat now.
It was being printed wrong as auto unsafe trait
9e7a5eb
to
5190abb
Compare
@bors r=nikomatsakis |
📌 Commit 5190abb has been approved by |
…omatsakis [Syntax] Implement auto trait syntax Implements `auto trait Send {}` as a substitute for `trait Send {} impl Send for .. {}`. See the [internals thread](https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086) for motivation. Part of #13231. The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the `optin_builtin_traits` feature gate. When can we remove the old syntax? Do we need to wait for a new `stage0`? We also need to formally decide for the new form (even if the keyword is not settled yet). Observations: - If you `auto trait Auto {}` and then `impl Auto for .. {}` that's accepted even if it's redundant. - The new syntax is simpler internally which will allow for a net removal of code, for example well-formedness checks are effectively moved to the parser. - Rustfmt and clippy are broken, need to fix those. - Rustdoc just ignores it for now. ping @petrochenkov @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
Breakage came from rust-lang/rust#45247
Implements
auto trait Send {}
as a substitute fortrait Send {} impl Send for .. {}
.See the internals thread for motivation. Part of #13231.
The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the
optin_builtin_traits
feature gate.When can we remove the old syntax? Do we need to wait for a new
stage0
? We also need to formally decide for the new form (even if the keyword is not settled yet).Observations:
auto trait Auto {}
and thenimpl Auto for .. {}
that's accepted even if it's redundant.ping @petrochenkov @nikomatsakis