impl Trait missed bound should hint if underlying type could satisfy the bound

[zesterer]

Code

use core::fmt::Debug;

fn accepts_copy(_x: impl Copy + Debug) {}

fn create_copyable() -> impl Debug { 42i32 }

fn main() {
    accepts_copy(create_copyable());
}

Current output

error[E0277]: the trait bound `impl Debug: std::marker::Copy` is not satisfied
 --> src/main.rs:8:19
  |
8 |     accepts_copy(create_copyable());
  |     ------------ ^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `impl Debug`
  |     |
  |     required by a bound introduced by this call
  |
note: required by a bound in `accepts_clone`
 --> src/main.rs:3:26
  |
3 | fn accepts_copy(_x: impl Copy + Debug) {}
  |                          ^^^^ required by this bound in `accepts_clone`

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

Desired output

error[E0277]: the trait bound `impl Debug: std::marker::Copy` is not satisfied
 --> src/main.rs:8:19
  |
8 |     accepts_copy(create_copyable());
  |     ------------ ^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `impl Debug`
  |     |
  |     required by a bound introduced by this call
  |
note: required by a bound in `accepts_clone`
 --> src/main.rs:3:26
  |
3 | fn accepts_copy(x: impl Copy + Debug) {}
  |                         ^^^^ required by this bound in `accepts_clone`
  |
note: underlying type `i32` implements `Copy`, consider changing the bound
  |
5 | fn create_copyable() -> impl Debug + Copy { 42i32 }
                                      +++++++

Rationale and extra context

I was inspired to report this by this issue.

In cases where the originator of the impl Trait type is 'owned' by the consumer (i.e: is in the same crate/workspace) and the underlying type is found to implement the required trait, a note that explains how to express this syntactically would be very useful.

This might even be a useful diagnostic even when the underlying type does not implement the required trait, although this is much more debatable.

Other cases

Rust Version

1.92.0-nightly (2025-09-14 52618eb338609df44978)

Anything else?

No response

[lcnr]

We have to be careful as fetching the hidden type may result in query cycles. I do agree that adding such a note here would be very nice however.

I feel like we should generally mention the hidden type of opaques (making sure to deal with overly large types) if they are relevant for error messages.