Refactor query forcing

[cjgillot]

The control flow in those functions was very complex, with several layers of continuations.

I tried to simplify the implementation, while keeping essentially the same logic.
Now, all code paths go through try_execute_query for the actual query execution.
Communication with the dep_graph and the live caches are the only difference between query getting/ensuring/forcing.

[rust-highfive]

r? @lcnr

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

@cjgillot does this need a perf run?

[cjgillot]

Should be perf-neutral, but a perf run can't hurt.

[jyn514]

Let's hold off then, it will get a perf run when it's merged and whoever does perf triage will see it if it's significant.

[Mark-Simulacrum]

Queries are generally quite hot, and it won't hurt - @bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 7dc39e324baf46e4990667269aa4dacd5655fd5f with merge bfb3e3391674a1abc7127c7552b0afd98fcc000f...

[bors]

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

[rust-timer]

Queued bfb3e3391674a1abc7127c7552b0afd98fcc000f with parent b1d9f31, future comparison URL.

[rust-timer]

Finished benchmarking try commit (bfb3e3391674a1abc7127c7552b0afd98fcc000f): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

[JohnCSimon]

ping from triage
@bjorn3 - can you address the requested changes from bjorn3? if you already have, can you please mark the change request resolved and alert the reviewer? thank you.

[bjorn3]

@cjgillot is the PR author, not me. Also all my review comments have been resolved.

[bors]

☔ The latest upstream changes (presumably #79721) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[jyn514]

ping @lcnr - are you a good reviewer for this? If not, can you suggest someone, maybe @wesleywiser?

[lcnr]

yeah, would prefer to hand this off 😅 this ended up slipping under my radar, sry

r? @wesleywiser feel free to reassign if you also can't review this rn

[wesleywiser]

Apologies, it's been a busy week for me and I haven't had time to look at this. It will probably be a few more days before I can take an in-depth look so if you don't want to wait that long, please feel free to re-assign; I don't want to hold this up 🙂

I do see some regressions in the performance data. Would it be feasible to try to narrow down which changes are causing that?

[bors]

☔ The latest upstream changes (presumably #80177) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[cjgillot]

Last perf run shows no runtime modification, and -8% on rustc_query_impl compile time.
I find the resulting code much simpler, -90 lines.
r? @wesleywiser

[Mark-Simulacrum]

Thanks! I looked over each commit, and while the code is definitely still not easily readable I think this is moving us in the right direction for sure, great work. Bootstrap time improvement is also nice to see.

I also think that the perf-regression label can be considered acceptable - the vast majority of benchmarks are showing slight improvements, with only a few of the smaller benchmarks showing regressions (helloworld, await-call-tree), and those are quite small too.

@rustbot label: +perf-regression-triaged

@bors r+

[Mark-Simulacrum]

@bors r+

(I think bors missed my earlier comment...)

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 31330bf has been approved by Mark-Simulacrum

[Mark-Simulacrum]

@bors rollup=never

[bors]

⌛ Testing commit 31330bf with merge 8c2b6ea...

[bors]

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

[rust-timer]

Finished benchmarking commit (8c2b6ea): comparison url.

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

• Moderate improvement in instruction counts (up to -0.9% on incr-full builds of unused-warnings)
• Small regression in instruction counts (up to 1.3% on incr-patched: println builds of coercions)

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

[Mark-Simulacrum]

@rustbot label: +perf-regression-triaged

The results are as expected before merging, with the majority being slightly positive, and the negative results limited to coercions-debug (typically noisy, though this may be a real data point) and helloworld (small, not very representative of normal code). Generally speaking, it seems like the improvements in bootstrap time and code quality are sufficient to accept these small regressions (and overall mixed results, given the wide swath of small improvements).