[Syntax] Implement auto trait syntax

[leoyvens]

Implements auto trait Send {} as a substitute for trait 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:

• 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

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[kennytm]

Some code are still using the old names.

[00:07:46] error[E0531]: cannot find tuple struct/variant `VtableDefaultImpl` in this scope
[00:07:46] --> /checkout/src/librustc/ich/impls_ty.rs:859:14
[00:07:46] |
[00:07:46] 859 | &VtableDefaultImpl(ref table_def_impl) => table_def_impl.hash_stable(hcx, hasher),
[00:07:46] | ^^^^^^^^^^^^^^^^^ not found in this scope
[00:07:46] [00:07:46] error[E0412]: cannot find type `VtableDefaultImplData` in module `traits`
[00:07:46] --> /checkout/src/librustc/ich/impls_ty.rs:887:13
[00:07:46] |
[00:07:46] 887 | for traits::VtableDefaultImplData<N> where N: HashStable<StableHashingContext<'gcx>> {
[00:07:46] | ^^^^^^^^^^^^^^^^^^^^^ did you mean `VtableAutoImplData`?
[00:07:46] [00:07:46] error[E0422]: cannot find struct, variant or union type `VtableDefaultImplData` in module `traits`
[00:07:46] --> /checkout/src/librustc/ich/impls_ty.rs:891:21
[00:07:46] |
[00:07:46] 891 | let traits::VtableDefaultImplData {
[00:07:46] | ^^^^^^^^^^^^^^^^^^^^^ did you mean `VtableAutoImplData`?
[00:07:46] [00:07:49] error[E0207]: the type parameter `N` is not constrained by the impl trait, self type, or predicates
[00:07:49] --> /checkout/src/librustc/ich/impls_ty.rs:886:12
[00:07:49] |
[00:07:49] 886 | impl<'gcx, N> HashStable<StableHashingContext<'gcx>>
[00:07:49] | ^ unconstrained type parameter

[leoyvens]

@kennytm Thanks, fixed it!

[nikomatsakis]

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

We could remove it ASAP, but it may be kind to offer a grace period. In the compiler itself, we can just use #[cfg(stage0)] impls for the time being.

[nikomatsakis]

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.

[nikomatsakis]

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.

[nikomatsakis]

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?

[nikomatsakis]

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.

[nikomatsakis]

Probably worth testing. =)

[nikomatsakis]

To work around the limitations of #[cfg(stage0)] and parsing, you could do something like this:

#[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 => {traitFoo{}impltraitFoofor .. {}}
stageN => {
auto trait Foo{}}}

but even better might be to make:

auto_trait!(Foo);

that expands to either auto trait Foo { } or trait Foo { } impl Foo for .. { } as appropriate.

[leoyvens]

@nikomatsakis Thanks, I'll work on killing off the old syntax then!

[nikomatsakis]

@rfcbot fcp merge

This PR changes the syntax of auto traits to be auto trait Foo { } instead of trait Foo { } impl Foo for .. { }. Regardless of the specific keyword that we choose, I think it's clear by now that co-induction (and auto-ness) is a propery of the trait, not an impl, and so it would be better to declare it at the trait level (e.g., the work on co-logic programming also talks of mixing inductive and co-inductive predicates, not of making co-inductive clauses). auto trait seems like it is a reasonable choice.

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.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

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.

[eddyb]

I'm not sold on the syntax but if we can't come up with anything more interesting/descriptive 🤷‍♂️

[cramertj]

@rfcbot reviewed

[leoyvens]

If we kill the old syntax now by abusing cfg(stage0) then when this becomes the stage0 it won't be able to boostrap itself. Better to wait for a stage0 that accepts both forms.

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.

@nikomatsakis

What do you think about simplifying the HIR representation to align better with the new syntax?

Coherence needs to check orphan rules, overlap and unsafety for hir::ItemAutoImpl which makes no sense for the new syntax. Refactorings that will just get removed in six weeks don't seem worth pursuing. But improvements to the representation of auto trait itself would make sense.

[bors]

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

[kennytm]

@bors r=nikomatsakis

[bors]

📌 Commit 5190abb has been approved by nikomatsakis

[bors]

⌛ Testing commit 5190abb with merge 2278506...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 2278506 to master...