[Draft] Supertrait item resolution in subtrait impls

[dingxiangfei2009]

r? @ghost

cc @cramertj @petrochenkov

This is pertaining to implementable trait aliases, Deref/Receiver trait migration and supertrait items in subtrait impls.

This is a draft for the resolver and crate metadata changes. Through this patch, the resolver will pick up supertrait items, collected from the trait super-bounds and trait alias in a future extension. This information will be encoded so that the resolver can resolve names in the downstream crates.

I would like to post this draft earlier because there are already significant design changes, which may warrant collecting opinions ahead of time.

Next steps would be

• teach hir-analysis to collect associated items in subtrait items into implied supertrait impls;
• adapt the syntax so that associated items can be paths instead of just identifies today, because associate items on paths is essential for the disambiguation of the design.

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

-    fn get_module_supertraits(self, id: DefIndex, sess: &'a Session) -> impl Iterator<Item = DefId> {
+    fn get_module_supertraits(
+        self,
+        id: DefIndex,
+        sess: &'a Session,
+    ) -> impl Iterator<Item = DefId> {
         let supertraits = self.root.tables.module_supertraits.get(self, id);
         supertraits.decode((self, sess)).into_iter()
     }
fmt: checked 6147 files
Build completed unsuccessfully in 0:00:44
  local time: Sun Jul  6 14:09:05 UTC 2025
  network time: Sun, 06 Jul 2025 14:09:06 GMT

[dingxiangfei2009]

This is not the desired end game, yet. This is rather a demonstration that this patch allows name resolution to associate A with that from trait Sup correctly.

[dingxiangfei2009]

cc @tmandry @tomassedovic

The patch is also to unblock arbitrary_self_types.

The next steps are

• (before landing this patch) gate the supertrait behaviour behind #[rustc_supertrait_in_subtrait_impl]
• Teach hir-analysis to generate an impl for supertraits
• Mark Deref with a builtin attribute #[rustc_supertrait_in_subtrait_impl], move Target from Deref to Receiver
  • Test the set up with crater

[petrochenkov]

We probably don't need this in AST.
This flag is needed after HIR->Ty lowering, I guess, and instead of parser it's equally simple to calculate it at any stage before that (e.g. in AST->HIR lowering, or HIR->Ty lowering).

[dingxiangfei2009]

I see that PolyTraitRef is used in several AST nodes including dyn, where bounds and the trait superbounds. Where would a better place be, to record whether the trait superbound has the auto impl modifier?

[dingxiangfei2009]

How about switching out parse_generic_bounds parser in fn parse_item_trait and we record the supertrait modifier, ie. with auto impl or not, on the trait item level?

[petrochenkov]

The auto impl modifier is in AST, yes.
Parser generally shouldn't be too context-sensitive and use things like in_supertrait_context, so it would typically parse auto impl everywhere and then later passes would reject it semantically in inappropriate positions.
Otherwise we have two separate but similar grammars for bound lists.

[petrochenkov]

But for a prototype both ways are ok, and if we need to track in_supertrait_context in the parser anyway for auto impl, then we can store it into AST too.

[petrochenkov]

LocalDefId shouldn't be a part of AST or AST visitors.
If it's needed by some specific visitor, it's better to pass it in some other way.

[petrochenkov]

What is auto impl Trait?
I don't see it in tests.
Is it a part of the "supertrait items in subtrait impls" feature, or some other related feature?

[dingxiangfei2009]

Yeah it was not included in the the "supertrait items in subtrait impls" feature but it is in the next proposal to handle the marker trait case.

Suppose that we have a marker trait trait Marker {} which has no associated items. The lang team discussion prefers the option to not automatically fill in an implicit impl Marker. Rather, we will first not fill it out and let the user to explicitly do impl Marker for .., unless the user writes trait Subtrait: auto impl Marker to allow the auto-impl.

[petrochenkov]

I don't think this is necessary.
Since use ChildTrait::ItemFromParent; and similar do not work and are not supposed to work, the whole implementation can be localized to compiler\rustc_resolve\src\late.rs.

Perhaps as two passes in late resolver.
Since if the first (regular) pass we do not always have trait Parent late-resolved when late-resolving

trait Child: Parent { ... }

, but we may need trait Parent late-resolved here.
So maybe the first pass can just keep a hole and some bookkeeping, so that the hole can be filled in a second pass.