auto-impl: parser support

[dingxiangfei2009]

View all comments

Tracking:

• Tracking Issue for Supertrait auto impl #149556

This patch introduce AST elements for auto impl inside the trait and impl block.

This patch does not handle the name resolution, yet. It will be handled in the next patch series.

RFC: rust-lang/rfcs#3851

cc

• trait evolution goal owner @cramertj
• correspondence @tmandry @tomassedovic

As a tracking issue is pending, I will link rust-lang/rust-project-goals#393 for more context.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a

HIR ty lowering was modified

cc @fmease

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ytmimi]

Can we add a simple formatting test for the AutoImpl changes added to rustfmt.

View changes since this review

[dingxiangfei2009]

I think the priority here is to first get parser code proof-read.

r? @petrochenkov

[petrochenkov]

It's probably more a language-related comment, than compiler-related, but the placement of auto impls doesn't seem right.

Auto impls are not associated items, they could very well live as free items, and placed into the traits just for the proximity.
Ideologically it would be similar if we supported placing inherent impls for structs into the struct body, C++ style (which is requested sometimes). We do not do that to support separation of data and implementation, here it would make sense to support separation of interfaces and implementation as well.
There are many comments on the RFC, so I'm not sure if it was already discussed.

Even from the compiler point of view in HIR and below we'd now need to separate real associated items from the things that just live there in source code, and may break some other assumptions across the compiler about only one level of associated item nesting existing, making building the prototype harder.

[petrochenkov]

The semicolon in auto impl SuperTrait {} -> auto impl SuperTrait; is an entirely orthogonal and optional feature.
It's not specific to auto impls and was proposed for regular impls before, but rejected.
I'd rather not even put this sugar into the RFC at this stage.

[petrochenkov]

Could you add some tests executing all the supported syntax, including const, of_trait and generics?

[petrochenkov]

(I'll continue the review tomorrow.)

[petrochenkov]

After reading the PR I'd again suggest to implement these impls as free items first, because you'll have a whole host of issues just from trying to move them from free to associated items.
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[dingxiangfei2009]

@rustbot ready

• We would like to confirm that auto impl is an AST and resolver-level associated item to trait items, not a type-level associated item.

[rust-bors]

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

[petrochenkov]

Again, my suggestion was to turn

trait BigTrait: Supertrait {
    auto impl Supertrait;
    fn foo(..);
}

into something like

trait BigTrait: Supertrait {
    fn foo(..);
}

auto impl Supertrait for BigTrait {} // or similar

so auto impls are never associated items at any IR level.

After the feature semantics are fully implemented in this and following PRs, we can consider moving them to associated items at some level, but that would be a separate work.

[dingxiangfei2009]

Thank you so much for reviewing @petrochenkov

[..] never associated items

cc @cramertj @tmandry @Darksonn

Okay I can do that. If we go down this route, I would further propose adding a keyword trait after the for keyword, in order to better distinguish it from normal impls.

auto impl $Supertrait for trait $Subtrait { .. }

How does it sound?

[traviscross]

auto impl $Supertrait for trait $Subtrait { .. }

How does it sound?

It makes sense to be syntactically explicit in some way here since one would otherwise expect that to be a type context. The other keyword that comes to mind as plausible would be impl (i.e. ... for impl Subtrait) by analogy with APIT (which actually should have been called "parameter position impl Trait"). I.e., with impl Super for bikeshed Sub, we're saying something to the effect of impl<T: Sub> Super for T. Using the APIT precedent (i.e., fn f<T: Tr>(x: T) ≅ fn f(x: impl Tr)), we could justify using impl in this type context to introduce a generic parameter with bounds.