Do not deduce parameter attributes during CTFE

[eggyal]

Ever since #103172, fn_abi_of_instance might look at a function's body to deduce certain codegen optimization attributes for its indirectly-passed parameters beyond what can be determined purely from its signature (namely today ArgAttribute::ReadOnly and ArgAttribute::CapturesNone). Since #130201, looking at a function's body in this way entails generating, for any coroutine-closures, additional by-move MIR bodies (which aren't represented in the HIR)—but this requires knowing the types of their context and consequently cycles can ensue if such bodies are generated before typeck is complete (such as during CTFE).

Since they have no bearing on the evaluation result, this patch breaks a subquery out from fn_abi_of_instance, fn_abi_of_instance_no_deduced_attrs, which returns the ABI before such parameter attributes are deduced; and that new subquery is used in CTFE instead (however, since parameter attributes are only deduced in optimized builds, as a performance optimization we avoid calling the new subquery unless we are performing such a build).

Fixes #151748
Fixes #152497

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[RalfJung]

Note that ABI "adjustments" typically do more than just deducing parameter attributes. So if "unadjusted" just refers to the attributes, that's confusing naming.

Also, having the full signature might be relevant for the UB checking that const-eval and Miri are doing. So it's at least slightly concerning that we shouldn't be able to access some of that info any more. What exactly is the difference between the signatures we obtain this way?

[RalfJung]

Looking at #151748, it seems like the underlying issue is that fn_sig_of_instance looks at the body of the function. That is indeed somewhat sus -- at least all the UB-relevant information should be deducible without the body. Please extend the PR description to explain this; it currently takes a bit of digging to fiure out what problem you're actually solving.

If we end up resolving this by splitting the query, it is very important that the queries have good documentation explaining their relationship. We want to avoid someone changing this code in the future in a way that removes too much information from the "unadjusted" signature.

[RalfJung]

That name and PR description are much better, thank you!

[RalfJung]

@bors try
@rust-timer queue

[RalfJung]

I gave some feedback on the comments. I have not looked at the actual code changes at all.

[tmiasko]

Annoyingly the fix that I originally proposed (most recently in 132a633)—that did not perform parameter deduction during CTFE but had a perf regression, would have also fixed the new case in #152497.

I think the compile time impact for debug and incremental is because tcx.sess.opts.optimize != OptLevel::No && tcx.sess.opts.incremental.is_none() condition is evaluated too late. That is, the code ends up evaluating both fn_abi_of_instance and fn_abi_of_instance_no_deduced_attrs queries. I would try to organize the code so that when this condition is false we effectively end up using only one of the queries.

[tmiasko]

When deduced attributes are ignored, i.e., tcx.sess.opts.optimize != OptLevel::No && tcx.sess.opts.incremental.is_none() is false, the behavior of both queries is equivalent. In that case we can choose one query and use it consistently in both code generation and CTFE to avoid the overhead of a query system.

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[eggyal]

Ugh. I appear to have messed up that rebase. Apologies...

@rustbot label: -A-LLVM

[RalfJung]

@bors try
@rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 2a788d9 (2a788d90a94638c4928810c15d9ba4d807467a1e, parent: 7ad4e69ad585d8ff214f7b42d01f1959eda08f40)

[rust-timer]

Finished benchmarking commit (2a788d9): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.1%]	4
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.0%	[-4.0%, -4.0%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	8.3%	[2.9%, 13.6%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.4%	[-6.9%, -3.6%]	3
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.915s -> 480.739s (-0.04%)
Artifact size: 398.15 MiB -> 396.14 MiB (-0.50%)

[eggyal]

Thanks @tmiasko ! 🎉

@rustbot ready