clone_from behaviour for ManuallyDrop

[m-ou-se]

With #[derive(Clone)] on ManuallyDrop<T>, x.clone_from(&y) will not drop the T inside x, just like x = y.clone(); does not drop the original x before overwriting it.

However, a manual implementation of clone_from can only make use of the efficiency of a overriden clone_from on T (e.g. memory reuse by a Vec::clone_from) by simply forwarding to it, which means that x.clone_from(&y) will not forget the old value.

This new (forwarding, so (potentially) dropping) behaviour was added in #85176, and (for now) reverted in #85758.

So question for @rust-lang/libs: What behaviour would be correct? There are arguments for both. Whatever the decision, we should document it and add a test for it.

[Amanieu]

I feel that the old behavior is correct (not calling drop). clone_from should behave like x = y.clone() which for ManuallyDrop means not dropping the old value.

I don't think there is much loss of efficiency in practice: use of clone_from is already pretty rare and I don't think there are any cases of it being used with ManuallyDrop.

[m-ou-se]

Sounds good. Closing this.

[m-ou-se]

Whatever the decision, we should document it and add a test for it.

No wait, we still need to do this part. :)