Add supertrait item shadowing for type-level path resolution by Amanieu · Pull Request #152225 · rust-lang/rust

Amanieu · 2026-02-06T13:46:03Z

This makes type-level name resolution (used primarily for associated types) also prefer subtrait items to supertrait items in case of ambiguity.

This addresses the concern from #148605 about the inconsistency with name resolution in expressions and method calls.

rustbot · 2026-02-06T13:46:08Z

HIR ty lowering was modified

cc @fmease

rustbot · 2026-02-06T13:46:10Z

r? @madsmtm

rustbot has assigned @madsmtm.
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

Why was this reviewer chosen?

The reviewer was selected based on:

People who recently interacted with files modified in this PR: compiler
compiler expanded to 20 candidates
Random selection from 12 candidates

jackh726 · 2026-02-09T18:50:25Z

+    println!("{}", size_of::<T::T>());
+}
+
+fn generic2<T: C<T = i16>>() {


What about T: B<T = i16> and T: A<T = i8> - do those resolve to B::T and A::T respectively?

Also, please use a different name for the generic and the associated type, it's a bit confusing as-is.

I've cleaned up the example and added tests showing how B<T = i16> and A<T = i8> are resolved.

jackh726 · 2026-02-09T19:12:31Z

r? types

madsmtm · 2026-02-26T10:50:37Z

r? types

Wait, I'm not sure if that should've unassigned me or not? In any case, if you also need a compiler reviewer, I'm the wrong one for the job, so I'm gonna unassign myself.

jackh726

In general, I think this needs some more tests. I've already commented about adding the testing attr, but ideally we should go through the existing tests/ui/methods/supertrait-shadowing tests (which in general are pretty thorough) and write the equivalent test for associated types and consts. These cover cases like multiple ancestors, unsatisfied trait bounds, scoping, and (in a PR I'm about to make) stability.

I also would like to see test that show that <U as A>::T works just fine, even if you have U: B.

View changes since this review

jackh726 · 2026-04-11T22:24:10Z

+use std::mem::size_of;
+
+trait A {
+    type T;


Please use a different name for the associated type to name lexically clash with the param.

jackh726 · 2026-04-11T22:29:22Z

+    println!("{}", size_of::<U::T>());
+}
+
+fn generic3<U: B<T = i16>>() {


What is missing here is a test of U: B<T = i8> and U: B, just to show the former is not callable (because of the blanket impl), and the latter still uses <U as B>::T. (Similar for C below)

jackh726 · 2026-04-11T22:32:39Z

+trait C: B {}
+impl<T> C for T {}
+
+fn main() {


We have rustc_dump_predicates, which we could use to verify the predicates are getting lowered as we expect. It would be good to use that in this (or another) test.

jackh726 · 2026-04-11T22:33:37Z

So, this test probably doesn't make sense here, right? This is not about method resolution.

Finally getting back around to this! Some questions about your preferences for the test organization.

Would you prefer moving all supertrait-shadowing tests into their own directory (tests/ui/supertrait-shadowing) or would you prefer adding a separate directory which just contains tests for type-level shadowing?

In the former case, would you like type-level shadowing tests to be in separate files or in the same file as the corresponding method-level test?

No strong preference. I think a separate directory is good. Putting them in the same file also seems reasonable.

jackh726 · 2026-04-11T22:35:31Z

+    /// supertrait of another candidate trait.
+    ///
+    /// This implements RFC #3624.
+    fn collapse_candidates_to_subtrait_pick(


I think docs here and for collapse_candidates_to_subtrait_pick in method::probe should link to each other to help ensure they are kept up to date.

It's kind of unfortunate we can't have some shared code here.

jackh726 · 2026-04-11T22:36:22Z

+                    continue;
+                }
+
+                // This pick is not a supertrait of the `child_pick`.


I have a commit with some cleanup that I'm about to push - but child_pick doesn't exist. Should be child_trait. Here and below.

joshtriplett · 2026-05-17T12:39:37Z

What's the current state of this PR? AIUI, this is the remaining blocker for stabilizing supertrait item shadowing.

jackh726 · 2026-05-17T19:54:45Z

I think this is waiting on @Amanieu to address the review.

Amanieu · 2026-06-04T22:32:17Z

I've addressed the review feedback. I couldn't adapt the following tests because the corresponding functionality doesn't exist in type-level name resolution, and always results in an ambiguity error:

trivially-false-subtrait.rs
unstable.rs
false-subtrait-after-inference.rs

rustbot · 2026-06-04T22:32:38Z

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.

jackh726 · 2026-06-08T17:34:18Z

I've addressed the review feedback. I couldn't adapt the following tests because the corresponding functionality doesn't exist in type-level name resolution, and always results in an ambiguity error:
* `trivially-false-subtrait.rs`
* `unstable.rs`
* `false-subtrait-after-inference.rs`

@Amanieu hmm for trivially-false-subtrait and false-subtrait-after-inference, these seem important, right? This basically means that associated type resolution doesn't take into account trait bounds but method resolution does...which seems like an important property to match

Generally, it's also interesting to me (and I must have missed this when I was going through) that false-subtrait-after-inference is ambiguous because of an inference variable...certainly for me it's obvious, but for the average user it feels weird. Especially because the error says i32: Foo doesn't hold, which a natural reaction should be "so don't pick it!" (which we don't if it's not an inference var)

Given the above, I'm wondering if may we want to limit that resolution even for the method case right now. Thoughts?

Amanieu · 2026-06-08T19:41:56Z

For trivially-false-subtrait there's no way to directly express the thing we're testing:

//@ run-pass

// Make sure we don't prefer a subtrait that we would've otherwise eliminated
// in `consider_probe` during method probing.

use core::mem::size_of;

#![allow(dead_code)]

struct W<T>(T);

trait Upstream {
    fn hello(&self) -> &'static str {
        "upstream"
    }
    type Assoc = i8;
}
impl<T> Upstream for T {}

trait Downstream: Upstream {
    fn hello(&self) -> &'static str {
        "downstream"
    }
    type Assoc = i16;
}
impl<T> Downstream for W<T> where T: Foo {}

trait Foo {}

fn main() {
    let x = W(1i32);
    assert_eq!(x.hello(), "upstream");

    // This doesn't work: accessing type-level associated items requires 
    // specifying the trait name explicitly with <W<i32> as Upstream> or
    // <W<i32> as Downstream>. But then that overrides supertrait shadowing
    // anyways...
    assert_eq!(size_of::<W<i32>::Assoc>(), 1);
    
    // This works but always resolves to the supertrait because that's what's
    // in the bounds of check1.
    check1::<W<i32>>();
    // This fails because W<i32> doesn't implement Downstream
    check2::<W<i32>>();
}

fn check1<T: Upstream>() {
    assert_eq!(size_of::<T::Assoc>(), 1);
}

fn check2<T: Downstream>() {
    assert_eq!(size_of::<T::Assoc>(), 2);
}

Similar issue with false-subtrait-after-inference.

Amanieu · 2026-06-08T19:54:58Z

Generally, it's also interesting to me (and I must have missed this when I was going through) that false-subtrait-after-inference is ambiguous because of an inference variable...certainly for me it's obvious, but for the average user it feels weird. Especially because the error says i32: Foo doesn't hold, which a natural reaction should be "so don't pick it!" (which we don't if it's not an inference var)

Given the above, I'm wondering if may we want to limit that resolution even for the method case right now. Thoughts?

That seems difficult to do in the current code structure, which I'm not super familiar with. Additionally, this is really an edge case: you would need to be intentionally shadowing a supertrait item while also having different trait bounds on the subtrait.

jackh726

This is fine - but we need test that shows that the feature needs to be enabled for this to work. (Though I can trivially see that this is true.)

After that, r=me

View changes since this review

Amanieu · 2026-06-08T21:21:51Z

This is fine - but we need test that shows that the feature needs to be enabled for this to work. (Though I can trivially see that this is true.)

Which feature are you talking about specifically? I'm not sure which of my comments you're replying to.

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 6, 2026

rustbot assigned madsmtm Feb 6, 2026

Amanieu mentioned this pull request Feb 9, 2026

Stabilize the supertrait_item_shadowing feature #148605

Open

jackh726 reviewed Feb 9, 2026

View reviewed changes

rustbot added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Feb 9, 2026

rustbot assigned jackh726 Feb 9, 2026

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

madsmtm removed their assignment Feb 26, 2026

Amanieu force-pushed the type-supertrait-shadowing branch from 1cde4c7 to 5a9ef14 Compare March 28, 2026 12:33

This comment has been minimized.

Sign in to view

jackh726 requested changes Apr 11, 2026

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 Apr 11, 2026

This comment has been minimized.

Sign in to view

Amanieu added 4 commits June 2, 2026 15:25

Add supertrait item shadowing for type-level path resolution

43d183d

Address review feedback

86455bf

Move supertrait shadowing tests to tests/ui/supertrait-shadowing

b7715df

Address review feedback for tests

9407a97

Amanieu force-pushed the type-supertrait-shadowing branch from 5a9ef14 to 9407a97 Compare June 4, 2026 22:32

jackh726 reviewed Jun 8, 2026

View reviewed changes

Uh oh!

Conversation

Amanieu commented Feb 6, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 6, 2026

Uh oh!

rustbot commented Feb 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 commented Feb 9, 2026

Uh oh!

madsmtm commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

jackh726 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!

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!

joshtriplett commented May 17, 2026

Uh oh!

jackh726 commented May 17, 2026

Uh oh!

This comment has been minimized.

Amanieu commented Jun 4, 2026

Uh oh!

rustbot commented Jun 4, 2026

Uh oh!

jackh726 commented Jun 8, 2026

Uh oh!

Amanieu commented Jun 8, 2026

Uh oh!

Amanieu commented Jun 8, 2026

Uh oh!

jackh726 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!

Amanieu commented Jun 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Amanieu commented Feb 6, 2026 •

edited by rustbot

Loading

madsmtm commented Feb 26, 2026 •

edited

Loading

jackh726 left a comment •

edited by rustbot

Loading

jackh726 left a comment •

edited by rustbot

Loading