auto-impl: parser support

[dingxiangfei2009]

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

[blyxyas]

I'm not really comfortable with a todo!() here. Please add a new variant to SourceItemOrderingTraitAssocItemKind

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

[bors]

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

[rust-bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

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