Optimize option clone

[ridiculousfish]

These two commits improve the codegen of Option::clone.

The first commit "specializes" Option<T: Copy>::clone to a memcpy. For example, prior to this PR, cloning an Option<[u8; 8]>) branches on the Option's discriminant (link). Copying the bytes without a branch is more efficient.

The second commit adds the same optimization but specialized for ops::Range. Range<T: Copy> is famously not Copy (see #27186 and related); I do not intend to necro that discussion but I would like to see a more efficient clone(). Because Range is not Copy, this version uses unsafe ptr::read to achieve the same effect.

Note: the first commit has a user-visible behavior change in that Option<T>::clone() will no longer invoke T::clone() if T is Copy. This was considered as OK in RFC 1521 but it might be worth calling out in release notes that it now affects Option.

[rust-highfive]

r? @joshtriplett

(rust_highfive has picked a reviewer for you, use r? to override)

[ridiculousfish]

I fully expect some pushback for the weird inclusion of Range inside Option, and am happy to pursue alternatives. I consider this PR as a jumping-off point for discussion for how to improve Option::clone's codegen, especially around Option<Range>.

[tesuji]

cc @matthewjasper because this PR uses specialization.

[cuviper]

Usually we want specialization to go through a private trait, so the ability to specialize is not part of the public API.

[scottmcm]

for the weird inclusion of Range inside Option

The thing that gets me here is that this also applies to every iterator -- a slice Iter also isn't copy, and could hypothetically benefit from this. So I'm not sure it makes sense to do it just for Range, but at the same time it also seems like overkill to do it for every single iterator adapter, for example.

--

A quick godbolt to show current codegen: https://rust.godbolt.org/z/YnG7rK

Brainstorming:

• This is reminding me of "trivial match removal" kinds of things, like [mir-opt] asking ?s in a more optimized fashion #66282 & [MIR-opt] trivial matches aren't optimized out at mir-opt-level=1 #66855. Maybe there's a MIR opt that could help?
• Is the clone derive normal, or compiler magic? The latter could presumably check the same kind of "it was derived so we can do funky things" logic that patterns do...

[pickfire]

@ridiculousfish nice to see you trying out rust. Off-topic, we rewrote fish-update-completions in rust and it is almost done (logging and testing left).

Usually we want specialization to go through a private trait, so the ability to specialize is not part of the public API.

@ridiculousfish Try checking out the recent vec extend iter changes for specialization, this change may need to do something similar.

[Dylan-DPC-zz]

@ridiculousfish any updates on this?

[ridiculousfish]

Sorry, this presumably needs more work than I can take on at the moment. Closing so it's not in th eway.