Create core::fmt::ArgumentV1 with generics instead of fn pointer

[nbdd0121]

Split from (and prerequisite of) #90488, as this seems to have perf implication.

@rustbot label: +T-libs

[rust-highfive]

r? @jackh726

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

[jyn514]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 2d042015faeb16b8ee59c98f2338c3573d1a805e with merge e7ca218bed4617e025bc0d11d072b26351ac6b29...

[bors]

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

[rust-timer]

Queued e7ca218bed4617e025bc0d11d072b26351ac6b29 with parent b416e38, future comparison URL.

[rust-timer]

Finished benchmarking commit (e7ca218bed4617e025bc0d11d072b26351ac6b29): comparison url.

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

• Large improvement in instruction counts (up to -2.4% on full builds of inflate)
• Large regression in instruction counts (up to 3.3% on full builds of tokio-webpush-simple)

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

[nbdd0121]

The perf run shows that this change generally improves typechecking perf of format_args! but there are seems to be some pathological cases regarding LLVM.

Manually inlining ArgumentV1::new into new_<trait> doesn't change the perf run result. Maybe adding #[inline(always)] could help.

Please queue another perf run, thanks!

[jackh726]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 1d60089fb0658e8d8fea6ce80833ea5855da18eb with merge c27884d95b11c30ef7e6320cfa2dd9772fce6b4a...

[bors]

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

[rust-timer]

Queued c27884d95b11c30ef7e6320cfa2dd9772fce6b4a with parent ad44239, future comparison URL.

[rust-timer]

Finished benchmarking commit (c27884d95b11c30ef7e6320cfa2dd9772fce6b4a): comparison url.

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

• Very large improvement in instruction counts (up to -6.0% on full builds of deeply-nested-closures)
• Moderate regression in instruction counts (up to 1.9% on full builds of cranelift-codegen)

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

[nbdd0121]

The later perf run shows that typeck is sped up in general, with some regression in debug profile codegen (which is expected, since #[inline(always)] will require LLVM to do more work). Is this regression acceptable or maybe shall I try #[inline] instead of #[inline(always)] to see the difference?

[joshtriplett]

I personally think this seems reasonable, but it's worth a perf run to see how regular inline fares.

[bors]

⌛ Testing commit b74eca7bee74116014db6b0bf6b14dd8562dbecb with merge 8036ccf3506596b40a474f9b2ffdde9f94e08879...

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

@bors r+ rollup=never

[bors]

📌 Commit 0d4bb0b has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 0d4bb0b with merge e58e7b1...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing e58e7b1 to master...

[rust-timer]

Finished benchmarking commit (e58e7b1): comparison url.

Summary: This benchmark run shows 59 relevant improvements 🎉 but 14 relevant regressions 😿 to instruction counts.

• Average relevant regression: 1.2%
• Average relevant improvement: -1.2%
• Largest improvement in instruction counts: -6.7% on full builds of tokio-webpush-simple opt
• Largest regression in instruction counts: 2.1% on full builds of keccak check

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

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression