Improve error message around unexpected derive bounds

[josephg]

Code

use std::sync::Arc;

// Not Clone
struct Foo;

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

fn main() {
    let x = Bar(Arc::new(Foo));
    x.clone(); // Error!
}

Current output

error[E0599]: the method `clone` exists for struct `Bar<Foo>`, but its trait bounds were not satisfied
--> src/main.rs:11:7
   |
4  | struct Foo;
   | ---------- doesn't satisfy `Foo: Clone`
...
7  | struct Bar<T>(Arc<T>);
   | ------------- method `clone` not found for this struct because it doesn't satisfy `Bar<Foo>: Clone`
...
11 |     x.clone(); // Error!
   |       ^^^^^ method cannot be called on `Bar<Foo>` due to unsatisfied trait bounds
   |
note: trait bound `Foo: Clone` was not satisfied
  --> src/main.rs:6:10
   |
6  | #[derive(Clone)]
   |          ^^^^^ unsatisfied trait bound introduced in this `derive` macro
help: consider annotating `Foo` with `#[derive(Clone)]`
   |
4  + #[derive(Clone)]
5  | struct Foo;
   |

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

Desired output

note: The implementation of Clone provided by #[derive(Clone)] on struct Bar
has a trait bound of "T: Clone". This may be overly restrictive. If the constraint
is incorrect, manually write an implementation of Clone for Bar without this
trait bound. For example:

impl Clone for Bar {
    fn clone(&self) -> Self {
        Self(self.0.clone())
    }
}

Rationale and extra context

Its quite surprising to many people that #[derive(Clone)] on a generic struct Foo<T> creates a trait implementation with a bound of T: Clone. Clone is trivially implementable for any type where all the fields implement Clone. The generic parameter itself is irrelevant.

You can - for example - have structs which can trivially be Cloned but where the trait is not clone (as in the example above). Or the inverse - for example, when a field is of type Cell<T> or Mutex<T>.

Currently the error does not sufficiently hint that this is the case. I personally spent half an hour fighting the compiler the first time I ran into it - I was confused how my #[derive(Clone)] was seemingly being ignored. There was a recent blog post about this issue which gathered over 100 comments on HN. Others are clearly running into this problem too.

The error message suggests the problem is with the lack of impl Clone for T. But this is a distraction. The right fix is often to manually implement Clone.

This blog post has some backstory on this choice within derive itself, and talks about how we might fix derive itself such that it doesn't have this pitfall. Unfortunately, doing so may have semver implications.

In the meantime, it'd be great to fix rustc's diagnostic message to at least point people in the right direction.

The diagnostic above should probably be added when all of these conditions are met:

1. .clone() is called (or default(), eq(), etc)
2. The type does not implement clone
3. There is a #[derive(Clone)] on the type
4. The type has generic parameters

Other cases

I've used Clone here an example, but the exact same problem shows up with other built in derive macros. For example, PartialEq, Default, Debug and so on.

Ideally, we should improve the diagnostics in all of these cases.

Rust Version

rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0

[estebank]

What do you think of the following:

error[E0599]: the method `clone` exists for struct `S<X, Y, X>`, but its trait bounds were not satisfied
  --> f802.rs:10:60
   |
4  | struct S<T, K, V>(Arc<T>, Rc<K>, Arc<V>, ());
   | ----------------- method `clone` not found for this struct because it doesn't satisfy `S<X, Y, X>: Clone`
5  | // struct S<T, K, V>(Arc<T>, T, Rc<K>, K, Arc<V>, V, ());
6  | struct X;
   | -------- doesn't satisfy `X: Clone`
...
10 |     S::<X, Y, X>(Arc::new(X), Rc::new(Y), Arc::new(X), ()).clone();
   |                                                            ^^^^^ method cannot be called on `S<X, Y, X>` due to unsatisfied trait bounds
   |
note: trait bound `X: Clone` was not satisfied
  --> f802.rs:3:10
   |
3  | #[derive(Clone)]
   |          ^^^^^ unsatisfied trait bound introduced in this `derive` macro
4  | struct S<T, K, V>(Arc<T>, Rc<K>, Arc<V>, ());
   |          ^     ^ unmet `Clone` bound on this type parameter
   |          |
   |          unmet `Clone` bound on this type parameter
   = note: `#[derive(Clone)]` introduces `where`-bounds requiring every type parameter to implement `Clone`, even when not strictly necessary: `impl<T: Clone, K: Clone, V: Clone> Clone for S<T, K, V> { /* .. */ }`
   = help: you can manually implement `Clone` with more targeted bounds: `impl<T, K, V> Clone for S<T, K, V> { /* .. */ }`
  --> f802.rs:4:10
   |
4  | struct S<T, K, V>(Arc<T>, Rc<K>, Arc<V>, ());
   |                   ----^-  ---^-  ----^- `Arc` already implements `Clone` independently of `V`
   |                   |       |
   |                   |       `Rc` already implements `Clone` independently of `K`
   |                   `Arc` already implements `Clone` independently of `T`
help: consider annotating `X` with `#[derive(Clone)]`
   |
6  + #[derive(Clone)]
7  | struct X;
   |

The new spans on the note would appear always, pointing only at the parameters that failed (if one of the fields was of type K, and K: !Clone, then it would be pointed at too).

The second to last help would show the bounds that would be needed for the current expression to be clone. If, for example, K were used as the type of a field directly, K: Clone would still be shown. I hesitate to provide a structured suggestion with all the code because of how long it would be.