Duplicate error when impl associated type is not well-formed

[Aaron1011]

The following code:

struct AssertCopy<T: Copy>(T);

trait Foo {
    type Assoc;
    fn my_method() -> Self::Assoc;
}

impl Foo for bool {
    type Assoc = AssertCopy<String>;
    fn my_method() -> Self::Assoc {
        panic!();
    }
}

produces the following two errors:

error[E0277]: the trait bound `String: Copy` is not satisfied
 --> src/lib.rs:9:5
  |
1 | struct AssertCopy<T: Copy>(T);
  |                      ---- required by this bound in `AssertCopy`
...
9 |     type Assoc = AssertCopy<String>;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String`

error[E0277]: the trait bound `String: Copy` is not satisfied
  --> src/lib.rs:10:23
   |
1  | struct AssertCopy<T: Copy>(T);
   |                      ---- required by this bound in `AssertCopy`
...
10 |     fn my_method() -> Self::Assoc {
   |                       ^^^^^^^^^^^ the trait `Copy` is not implemented for `String`

Only the first error is useful - the second error occurs because we're trying to use the 'malformed' associated type. This can be especially bad when proc-macros are involved, since the span of the return type might not be meaningful. See #83383

We should suppress the second error.

[eggyal]

Of course, it's perfectly valid for the impl to have explicitly replaced the Self::Assoc in my_method's return type with AssertCopy<String> ... presumably the error should still be suppressed in that case, but doing so presumably requires checking the signature in the trait?

[Aaron1011]

I would argue that we shouldn't suppress the error when AssertCopy<String> is explicitly written in the return type. In general, we shouldn't deduplicate well-formed errors for the same type - AssertCopy<String> could be written in two completely unrelated in the project, and we'd want to tell the user that there are two distinct problems with their code.

With an associated type, the error is caused by the concrete type that it resolves to, so displaying it multiple times doesn't really provide any additional information.