Mark String::clone as inline-able

[notriddle]

It calls Vec::clone and performs a newtype-wrap around it, so it should be trivial enough that it doesn't cause major size regressions. It also fixes #88905

[rust-highfive]

r? @dtolnay

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

[camelid]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit e32f90c with merge 4997354d85d9c0ea35ae9df9300fa1db9de4997b...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4997354d85d9c0ea35ae9df9300fa1db9de4997b (4997354d85d9c0ea35ae9df9300fa1db9de4997b)

[rust-timer]

Queued 4997354d85d9c0ea35ae9df9300fa1db9de4997b with parent 9bb77da, future comparison URL.

[rust-timer]

Finished benchmarking commit (4997354d85d9c0ea35ae9df9300fa1db9de4997b): comparison url.

Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.

• Moderate improvement in instruction counts (up to -0.8% on incr-patched: b9b3e592dd cherry picked builds of style-servo)
• Small regression in instruction counts (up to 2.1% on incr-patched: println builds of regression-31157)

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

[camelid]

Hmm, seems like the results are quite mixed. It could be worth doing another perf run to see if the results are spurious, but I'll let T-libs decide.

[the8472]

Note that LTO does inline this, it'll only benefit non-LTO builds.

[dtolnay]

I am not convinced that it is worth making this change. Is there a common idiom that leads to strings getting cloned and never used? If this is minimized from real world code then we can evaluate vs the costs of inline, but I am having trouble seeing how this would come up in a hot path in practice.