`clone_double_ref` doesn't help if the result leads to a compiler error

See for example this snippet:

struct NonCopy;

fn main() {
    let copy: NonCopy = (&NonCopy).clone();
}

It doesn't compile because of the type mismatch (expected struct NonCopy, found &NonCopy) and the lint isn't shown even though the clone of the double ref is what causes the issue.

In this small example, it's trivial to spot the error, however, in real code, the error may be caused by something less obvious and a lot harder to debug without knowing that the reference was cloned. For example, I've found a similar problem in generic async code where lifetime mismatch error was very confusing.

Is it possible to run this lint even if the compilation failed?

@rustbot label +C-enhancement

Start by reproducing the provided clone_double_ref example and inspect how this lint is triggered when type checking fails. Trace the lint's compiler integration to determine whether diagnostics can still be emitted after the compilation error, then add coverage for the example and verify that the lint appears alongside the type error.