Querify FnAbi::of_{fn_ptr,instance} as fn_abi_of_{fn_ptr,instance}.

[eddyb]

Note: opening this PR as draft because it's based on #88499

This more or less replicates the LayoutOf::layout_of setup from #88499, to replace FnAbi::of_{fn_ptr,instance} with FnAbiOf::fn_abi_of_{fn_ptr,instance}, and also route them through queries (which layout_of has used for a while).

The two changes at the use sites (other than the names) are:

• return type is now wrapped in &'tcx
  • the value is interned, which may affect performance
• the extra_args list is now an interned &'tcx ty::List<Ty<'tcx>>
  • should be cheap (it's empty for anything other than C variadics)

Theoretically, a FnAbiOfHelpers implementer could choose to keep the Result<...> instead of eagerly erroring, but the only existing users of these APIs are codegen backends, so they don't (want to) take advantage of this.
At least miri could make use of this, since it prefers propagating errors (it "just" doesn't use FnAbi yet - cc @RalfJung).

The way this is done is probably less efficient than what is possible, because the queries handle the correctness-oriented API (i.e. the split into fn pointers vs instances), whereas a lower-level query could end up with more reuse between different instances with identical signatures.

r? @nagisa cc @oli-obk @bjorn3

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[eddyb]

Thanks to #88499 (comment) (i.e. #88499 being perf-neutral), we should be able to get useful data despite this being based on #88499:

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit c4b36be083fe7fcc74e824b1e15368094d58fbf8 with merge eb6a18b59b113d9f9fde80bfc8c1e43dca27c954...

[bors]

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

[rust-timer]

Queued eb6a18b59b113d9f9fde80bfc8c1e43dca27c954 with parent 50171c3, future comparison URL.

[RalfJung]

At least miri could make use of this, since it prefers propagating errors (it "just" doesn't use FnAbi yet - cc @RalfJung).

Yeah, it's on my list...
For LayoutOf, I think we have to properly propagate errors or some CTFE or pattern matching code will end up ICEing. Not sure if the same concern applies here.

[rust-timer]

Finished benchmarking try commit (eb6a18b59b113d9f9fde80bfc8c1e43dca27c954): comparison url.

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

• Moderate improvement in instruction counts (up to -0.8% on full builds of regression-31157)
• Moderate regression in instruction counts (up to 1.8% 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 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

[bjorn3]

Unfortunately this is a clear perf regression.

[oli-obk]

Yea, imo we can merge this if we have an issue for the incremental-unchanged regression that somewhat collects the information from this discussion

[wesleywiser]

+1, seems ok to merge to me.

[nagisa]

@bors r+ rollup=never

[bors]

📌 Commit 8c918d7 has been approved by nagisa

[bors]

⌛ Testing commit 8c918d7 with merge 9119882...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing 9119882 to master...

[rust-timer]

Finished benchmarking commit (9119882): comparison url.

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

• Moderate improvement in instruction counts (up to -1.0% on full builds of regression-31157)
• Moderate regression in instruction counts (up to 1.4% on incr-unchanged builds of regression-31157)

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

[pnkfelix]

Visited for weekly performance triage. Results do indeed seem moderately mixed.

[eddyb]

@pnkfelix It's a bit more subtle than that (only incr-{unchanged,patched} regressed), and it got discussed before landing (in fact I personally wasn't sure this could land any time soon), see #88575 (comment).