auto-impl: parser support #149335

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

compiler/rustc_parse/src/parser/item.rs

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. Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>

ytmimi

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

View changes since this review

dingxiangfei2009 · 2025-12-01T15:40:32Z

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

r? @petrochenkov

blyxyas · 2025-11-26T17:12:47Z

src/tools/clippy/clippy_lints/src/arbitrary_source_item_ordering.rs

        AssocKind::Const { .. } => Const,
        AssocKind::Type { .. } => Type,
        AssocKind::Fn { .. } => Fn,
+        AssocKind::AutoImpl => todo!(),


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

petrochenkov · 2025-12-02T15:31:36Z

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 · 2025-12-02T15:39:11Z

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 · 2025-12-02T15:51:51Z

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

petrochenkov · 2025-12-02T15:53:35Z

compiler/rustc_ast/src/ast.rs

            | ItemKind::DelegationMac(_)
            | ItemKind::MacroDef(..) => None,
            ItemKind::Static(_) => None,
+            ItemKind::AutoImpl(_) => None,


There are generics in AutoImpl, but this returns None.

petrochenkov · 2025-12-02T15:58:02Z

compiler/rustc_ast_pretty/src/pprust/state/item.rs

+                    self.print_assoc_item(impl_item);
+                }
+                let empty = item.attrs.is_empty() && items.is_empty();
+                self.bclose(item.span, empty, cb);


print_assoc_auto_impl was supposed to be reused here?

petrochenkov · 2025-12-02T16:01:40Z

compiler/rustc_feature/src/unstable.rs

    /// Allows `super let` statements.
    (unstable, super_let, "1.88.0", Some(139076)),
+    /// Allows supertraits to be implemented with automatic defaults
+    (unstable, supertrait_auto_impl, "CURRENT_RUSTC_VERSION", Some(99999)),


There's no tracking issue for the experiment?
Probably need a lang team approval and a tracking issue to start.

Thanks @petrochenkov for raising this. You're right; this should have a tracking issue documenting the lang experiment and its champion. Talked with @dingxiangfei2009, after he pinged me, and he's filing the tracking issue for this, which we'll nominate and discuss in a meeting.

petrochenkov · 2025-12-02T16:05:44Z

compiler/rustc_resolve/src/late.rs

+                self.r
+                    .tcx()
+                    .dcx()
+                    .emit_err(errors::AutoImplOutsideTraitOrImplTrait { span: item.span });


This belongs to ast_validation.rs, or AST lowering, or something like that.

petrochenkov · 2025-12-02T16:06:56Z

compiler/rustc_resolve/src/late.rs

                }
+                AssocItemKind::AutoImpl(_ai) => {
+                    let tcx = self.r.tcx();
+                    if !tcx.features().supertrait_auto_impl() {


Since this is a new syntax, feature gating needs to be done in parser using gated_spans.

petrochenkov · 2025-12-02T16:09:51Z

(I'll continue the review tomorrow.)

petrochenkov · 2025-12-03T11:50:17Z

compiler/rustc_ast_lowering/src/item.rs

                    constness,
                })
            }
+            ItemKind::AutoImpl(box AutoImpl { .. }) => todo!("we should implement lowering to HIR"),


Could you report a regular error instead of an ICE here and for AssocItemKind::AutoImpl?
Upd: and in other crates too.

Or report a fatal error in lowering and turn todo!s into unreachable!s in the later compilation stages.

petrochenkov · 2025-12-03T11:50:34Z

compiler/rustc_ast_lowering/src/item.rs

+            AssocItemKind::AutoImpl(ai) => {
+                let tcx = self.tcx;
+                if !tcx.features().supertrait_auto_impl() {
+                    feature_err(


Feature gating once in the parser should be enough.

petrochenkov · 2025-12-03T11:55:21Z

compiler/rustc_hir_analysis/src/collect/generics_of.rs

-            // Re. GATs and GACs (generic_const_items), we're not bound by backward compatibility.
            ImplItemKind::Const(..) | ImplItemKind::Type(..) => ParamDefaultPolicy::Forbidden,
            ImplItemKind::Fn(..) => ParamDefaultPolicy::FutureCompatForbidden,
+            ImplItemKind::AutoImpl(..) => ParamDefaultPolicy::Forbidden,


Suggested change

ImplItemKind::AutoImpl(..) => ParamDefaultPolicy::Forbidden,

ImplItemKind::AutoImpl(..) | ImplItemKind::ExternImpl(..) => ParamDefaultPolicy::Forbidden,

petrochenkov · 2025-12-03T11:58:55Z

compiler/rustc_hir_pretty/src/lib.rs

+            hir::ImplItemKind::AutoImpl(poly_trait_ref, impl_items) => {
+                let (cb, ib) = self.head("");
+                self.word_nbsp("auto");
+                self.word_nbsp("impl");


Maybe factor out the common parts like in AST printing?

petrochenkov · 2025-12-03T12:02:01Z

compiler/rustc_hir/src/hir.rs

+    /// An `auto impl` implementation
+    AutoImpl(&'hir PolyTraitRef<'hir>, &'hir [ImplItem<'hir>]),
+    /// An `extern impl` directive
+    ExternImpl(&'hir PolyTraitRef<'hir>),


Where is ExternImpl actually generated?
I don't see being produced by AST lowering.

petrochenkov · 2025-12-03T12:05:16Z

compiler/rustc_privacy/src/lib.rs

        let (check_ty, is_assoc_ty) = match item.kind {
            ty::AssocKind::Const { .. } | ty::AssocKind::Fn { .. } => (true, false),
            ty::AssocKind::Type { .. } => (item.defaultness(self.tcx).has_value(), true),
+            ty::AssocKind::AutoImpl => return,


I'm pretty sure the auto impls should be privacy-checked here too.

petrochenkov · 2025-12-03T12:07:40Z

compiler/rustc_resolve/src/build_reduced_graph.rs

-        if ctxt == AssocCtxt::Trait {
+        if let AssocItemKind::AutoImpl(_) = item.kind {
+            // We do not define any local names.
+            // We will now recursively descend into `auto impl`


Why not? This doesn't seem right.

petrochenkov · 2025-12-03T12:26:50Z

compiler/rustc_parse/src/parser/item.rs

            self.bump(); // `union`
            self.parse_item_union()?
+        } else if self.check_keyword(exp!(Unsafe))
+            && self.is_keyword_ahead(1, &[kw::Auto, kw::Impl])


This catches non-auto unsafe impl.

petrochenkov · 2025-12-03T12:31:23Z

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 · 2025-12-03T12:31:28Z

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

BoxyUwU · 2025-12-07T18:38:13Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

                    }
                    ty::AssocKind::Const { .. } => None,
+                    // This does not change judgement on GAT
+                    ty::AssocKind::AutoImpl => continue,


I don't want the type system to have to care about a new assoc kind. Also please get types approval before having this merged (I've assigned myself). Why is this PR doing more than just parser stuff like the title and PR description indicates?

bors · 2025-12-14T08:51:18Z

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

rustbot assigned fee1-dead Nov 25, 2025

fmease reviewed Nov 25, 2025

View reviewed changes

compiler/rustc_parse/src/parser/item.rs Outdated Show resolved Hide resolved

auto-impl: parser support

fac5797

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. Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>

dingxiangfei2009 force-pushed the supertrait-auto-impl branch from 644d1ce to fac5797 Compare November 25, 2025 23:07

ytmimi reviewed Nov 28, 2025

View reviewed changes

rustbot assigned petrochenkov and unassigned fee1-dead Dec 1, 2025

blyxyas reviewed Dec 1, 2025

View reviewed changes

petrochenkov reviewed Dec 2, 2025

View reviewed changes

dingxiangfei2009 mentioned this pull request Dec 2, 2025

Tracking Issue for Supertrait auto impl #149556

Open

21 tasks

petrochenkov reviewed Dec 3, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 3, 2025

tomassedovic mentioned this pull request Dec 5, 2025

Getting Rust for Linux into stable Rust: language features rust-lang/rust-project-goals#116

Open

53 tasks

BoxyUwU self-assigned this Dec 7, 2025

BoxyUwU reviewed Dec 7, 2025

View reviewed changes

traviscross added the I-lang-radar Items that are on lang's radar and will need eventual work or consideration. label Dec 10, 2025

	ImplItemKind::AutoImpl(..) => ParamDefaultPolicy::Forbidden,
	ImplItemKind::AutoImpl(..) \| ImplItemKind::ExternImpl(..) => ParamDefaultPolicy::Forbidden,

Uh oh!

auto-impl: parser support #149335

Are you sure you want to change the base?

auto-impl: parser support #149335

Uh oh!

Conversation

dingxiangfei2009 commented Nov 25, 2025 • edited by traviscross Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Nov 25, 2025

Uh oh!

rustbot commented Nov 25, 2025

Uh oh!

Uh oh!

ytmimi left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dingxiangfei2009 commented Dec 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Dec 2, 2025

Uh oh!

petrochenkov commented Dec 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Dec 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Dec 3, 2025

Uh oh!

rustbot commented Dec 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Dec 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

dingxiangfei2009 commented Nov 25, 2025 •

edited by traviscross

Loading

ytmimi left a comment •

edited by rustbot

Loading

petrochenkov commented Dec 2, 2025 •

edited

Loading

traviscross Dec 2, 2025 •

edited

Loading