Skip to content

Don't use item name to look up associated item from trait item #140278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 25, 2025
Merged

Don't use item name to look up associated item from trait item #140278

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 5 additions & 7 deletions compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1523,19 +1523,17 @@ impl<'a, 'tcx> TypeErrCtxt<'a, 'tcx> {
return None;
};

let trait_assoc_item = self.tcx.opt_associated_item(proj.projection_term.def_id)?;
let trait_assoc_ident = trait_assoc_item.ident(self.tcx);

let mut associated_items = vec![];
self.tcx.for_each_relevant_impl(
self.tcx.trait_of_item(proj.projection_term.def_id)?,
proj.projection_term.self_ty(),
|impl_def_id| {
associated_items.extend(
self.tcx
.associated_items(impl_def_id)
.in_definition_order()
.find(|assoc| assoc.ident(self.tcx) == trait_assoc_ident),
self.tcx.associated_items(impl_def_id).in_definition_order().find(
Copy link
Member Author

@compiler-errors compiler-errors Apr 25, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note on item ordering: RPITITs are typically last in this list, so we typically do not encounter RPITITs here (and thus, it's harder to reproduce this ICE).

However, when we have a macro, the identifier of the macro wasn't being adjusted, so although it had the same Symbol, it has a different span and thus identifier equality works a bit differently. So we fall through the assoc item list to the RPITITs, and try to compute their item names and ICE.

|assoc| {
assoc.trait_item_def_id == Some(proj.projection_term.def_id)
},
),
);
},
);
Expand Down
23 changes: 23 additions & 0 deletions tests/ui/impl-trait/in-trait/dont-probe-missing-item-name-4.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
trait ServerFn {
type Output;
fn run_body() -> impl Sized;
}
struct MyServerFn {}

macro_rules! f {
() => {
impl ServerFn for MyServerFn {
type Output = ();
fn run_body() -> impl Sized {}
}
};
}

f! {}

fn problem<T: ServerFn<Output = i64>>(_: T) {}

fn main() {
problem(MyServerFn {});
//~^ ERROR type mismatch resolving `<MyServerFn as ServerFn>::Output == i64`
}
26 changes: 26 additions & 0 deletions tests/ui/impl-trait/in-trait/dont-probe-missing-item-name-4.stderr
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
error[E0271]: type mismatch resolving `<MyServerFn as ServerFn>::Output == i64`
--> $DIR/dont-probe-missing-item-name-4.rs:21:13
|
LL | problem(MyServerFn {});
| ------- ^^^^^^^^^^^^^ type mismatch resolving `<MyServerFn as ServerFn>::Output == i64`
| |
| required by a bound introduced by this call
|
note: expected this to be `i64`
--> $DIR/dont-probe-missing-item-name-4.rs:10:27
|
LL | type Output = ();
| ^^
...
LL | f! {}
| ----- in this macro invocation
note: required by a bound in `problem`
--> $DIR/dont-probe-missing-item-name-4.rs:18:24
|
LL | fn problem<T: ServerFn<Output = i64>>(_: T) {}
| ^^^^^^^^^^^^ required by this bound in `problem`
= note: this error originates in the macro `f` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0271`.
Loading