Explain why &T is cloned when T is not Clone

[compiler-errors]

Fixes #95535

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[notriddle]

This seems like it’s redundant with the https://github.com/rust-lang/rust/blob/master/compiler/rustc_lint/src/noop_method_call.rs lint, which is disabled right now, but would accomplish the same thing.

Is it desirable to merge this, and then remove it later when the lint gets stabilized?

[compiler-errors]

@notriddle, given this code

#![warn(noop_method_call)]

struct PlainType<T>(T);

pub fn foo(non_clone_type_ref: &PlainType<u32>) -> PlainType<u32> {
    non_clone_type_ref.clone()
}

The suggestion I added fires, since it's a suggestion on the type error, but the noop method call lint does not... I don't know very much about how late lints work, do you know if it only fires if typeck succeeds? If so, then it doesn't seem like we can deduplicate the logic here.

[notriddle]

It looks like it doesn’t run when there’s a type error, but this is a known issue, if I’m understanding #91536 correctly.

[compiler-errors]

Interesting! Thanks for pointing that out. I may take a look at that issue..

[bors]

☔ The latest upstream changes (presumably #95667) made this pull request unmergeable. Please resolve the merge conflicts.

[estebank]

@compiler-errors it's a long standing issue for lints that would help not triggering in the face of errors. It is also better (if more work) to consolidate useful information in the earliest possible error and avoid the later ones (or, as we do in some cases, keep information around from the first error, not emit it, and extend the later one).

[estebank]

r=me after rebase <3

[compiler-errors]

@bors r=estebank

[bors]

📌 Commit d12689c has been approved by estebank

[estebank]

(potential follow up work?/random thought) adding a label to this span to say "this is of type NotClone" might be useful (particularly for longer method chains).