#[derive(Clone)] doesn't even implement clone_from() and the default clone_from() is implemented as *self = source.clone()

There are some false positives but they're from manual implementations in wrapper types (#12709). Directly at least types without a manual implementation of clone_from are ignored

Ah, that's cool. I didn't know that.

But I still think clippy is suggesting to do a premature optimization. In code where this level of performance difference is truly important, the difference should be bench-marked.

I don't think this trade-off between absolute maximum possible performance and code readability is a proper one for the default configuration of clippy.

I got this warning from a String, but I really don't think the potential performance improvement is worth making the code less readable.

Especially considering that #[derive(Clone)] doesn't even implement clone_from() and the default clone_from() is implemented as *self = source.clone():

Note that there's a catch-22 here: using clone_from() has little benefit because very few Clone implementations override it, and very few Clone implementations override it because it is so rarely used. I hoped that by creating assigning_clones, this cycle would be broken.

That's true. But even if this gives a runtime performance improvement, I don't think this lint should be enabled by default. It favors a small performance gain over a big readability loss.

This kind of optimization may save a call to alloc and free in practise. If this is important enough, the compiler should try to figure this out and re-use the allocation behind the scenes (I think many C++ compilers do this nowadays?).

I really feel that telling people not to use the = operator for assigning values is the wrong thing to do as a default.

/edit: Reading the zulip conversation the consensus also seems to be to put it in pedantic? https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Meeting.202023-05-02/near/355185136