missed optimimization: needless clone of stdlib non-copy type is not eliminated

[lolbinarycat]

code: https://rust.godbolt.org/z/5M1nnhEbY (godbolt isn't letting me copy it for some reason)

compiler version: 1.85.0

I understand that technically Clone can have side effects, but standard library types should be able to use some sort of perma-unstable attribute to assert that their Clone impl does not (technically calling the allocator is an arbitrary side-effect, but i believe rust already has a policy that allocations can be eliminated).

Types that use derive(Clone), where all of the fields are pure types, should also have their clone impls marked as safe.

[Urgau]

Could you use our "Bug Report" issue template, it provides explicit "I expected to see this happen", as well as "Instead, this happened", which makes it easier to see the issue your trying to report here. It's not much more, but at least for me it's much easier to read than your current blob of text.

Regarding the issue it-self, your point is that <alloc::string::String as core::clone::Clone>::clone shouldn't be called but instead should be not be present? bc it's inlined or something. (stating that here because it's not clear from your bug report and I want to make sure it's 100% clear)

[lolbinarycat]

Sorry, I was initially going to provide a counterexample of clone being eliminated because I thought the current behavior was more complex than it turned out to be, which would've made this really not fit in the template.

I said the call should be eliminated (replaced with a move) when the clone is not required.

I'm not sure if the compiler has an optimization pass this would fit into, but it seems like it could have a moderate impact on certain classes of generic and generated code.