Specialize derive(Clone) to use Copy when applicable

[fee1-dead]

In this PR I added two internal items in core::clone: try_copy and DerivedClone.

try_copy will copy from &T to T if it can, and call a function when it cannot.

The derive impl for Clone is changed such that it generates a call to try_copy(self, DerivedClone::clone), and the impl for DerivedClone contains the derive impl before this PR.

Internally:
I added a field to TraitDef named bound_current_trait that disables addition of generic bounds of the trait that is being implemented. This prevents bounding on DerivedClone when we are generating that impl.

[rust-highfive]

r? @jackh726

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

[fee1-dead]

Could be perf sensitive, so:

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 95183ec with merge 074fe5f224a2ee59233947b06ddfd86252e1086c...

[bors]

☀️ Try build successful - checks-actions
Build commit: 074fe5f224a2ee59233947b06ddfd86252e1086c (074fe5f224a2ee59233947b06ddfd86252e1086c)

[rust-timer]

Queued 074fe5f224a2ee59233947b06ddfd86252e1086c with parent 306ba83, future comparison URL.

[rust-timer]

Finished benchmarking commit (074fe5f224a2ee59233947b06ddfd86252e1086c): comparison url.

Summary:

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	114	65	10	22	124
mean2	1.1%	3.7%	-0.7%	-0.5%	0.9%
max	3.2%	9.2%	-1.3%	-1.0%	3.2%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[jackh726]

Do you need me to review this prior to fixing perf?

[fee1-dead]

Yes, I think perf might be unavoidable.

[jackh726]

What's the point of this, if not perf?

[fee1-dead]

compiler perf will definitely be negatively affected since we now emit two items for the derive. The question would be, "are there people who implement Copy manually or derive(Copy) in a different attribute while deriving clone?"

If there is a significant amount of them, then I think this would definitely be beneficial. But now it doesn't seem to have much of a benefit. Maybe we could discuss the possibility of doing something like this with perfect derives.

[scottmcm]

Note that in the case of something like

#[derive(Clone)]
pub struct Foo(usize, HashSet<String>, usize);

The mir-opt in #94276 will replace the clone calls on the primitives with copies pretty early, to simplify the MIR.

So that along with LLVM being pretty good at inlining the clones enough to notice they're actually copies (even the MIR inliner can often do this, though it's not on yet), it's possible that most of the low-hanging fruit here has already been picked.