The compiler should be more helpful when trait bounds are not met.

[glandium]

Here's a reduced testcase:

use std::sync::Arc;

struct Foo;

#[derive(Clone)]
struct Bar<T>(Arc<T>);

fn main() {
    let a = Bar(Arc::new(Foo));
    let b = a.clone();
}

This fails to compile with:

error[E0599]: no method named `clone` found for type `Bar<Foo>` in the current scope
  --> src/main.rs:10:15
   |
6  | struct Bar<T>(Arc<T>);
   | ---------------------- method `clone` not found for this
...
10 |     let b = a.clone();
   |               ^^^^^
   |
   = note: the method `clone` exists but the following trait bounds were not satisfied:
           `Bar<Foo> : std::clone::Clone`
   = help: items from traits can only be used if the trait is implemented and in scope
   = note: the following trait defines an item `clone`, perhaps you need to implement it:
           candidate #1: `std::clone::Clone`

The way #[derive] works (#26925), and with 20/20 hindsight, it's obvious what's wrong. But even when you know about #26925 it takes a mental effort to go from that error message to "oh, right, #[derive(Clone)] adds T: Clone".

It would be useful if the compiler went further, and, considering there is an impl Clone for Bar<T>, detailed why that impl doesn't apply to Foo.

[glandium]

Come to think of it, it's more general than #26925. One could hit a similar error with custom impls of any trait and the information why the generic impl doesn't match would be valuable in those cases too.

[d-e-s-o]

I'd honestly go one step further and consider implementing Clone without the requirement T: Clone iff there is no need, e.g., if there is an inner type wrapping the T that does not require T: Clone on its implementation of Clone, as is the case for Arc:

impl<T> Clone for Arc<T>
where
    T: ?Sized,

(not sure how feasible that is [or whether I missed something in my reasoning], but it may be something worth shooting for)