Name the captured upvars for closures/generators in debuginfo

[lrh2000]

Previously, debuggers print closures as something like

y::main::closure-0 (0x7fffffffdd34)

The pointer actually references to an upvar. It is not very obvious, especially for beginners.

It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like

y::main::closure-0 {_captured_ref__b: 0x[...]}

r? @tmandry
Discussed at #84752 (comment) .

[tmandry]

Looks good! I left a few comments.

[lrh2000]

I haven't split closures from TupleMemberDescriptionFactory because now generators are also mixed in EnumMemberDescriptionFactory. I guess a full refactor of the code may split generators from EnumMemberDescriptionFactory as well?

I have addressed other comments. Besides, now upvar names are stored in mir::Body::var_debug_info. So they can be referenced at breakpoints inside the closure (as shown by a new test case). And it solves issues against external closures (#85020 (comment)), but there are not test cases since I don't think our test system can test multiple crates (right?).

[tmandry]

Looks good, thanks. Building a new symbol for every capture in mir-build could impact perf, so

@bors try
@rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit fc900b3a86b03476941f4a4b81ab4bfd7000a62b with merge 572ac0ed693592bcc032c44e9272d9dd52db6385...

[bors]

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

[rust-timer]

Queued 572ac0ed693592bcc032c44e9272d9dd52db6385 with parent 607d6b0, future comparison URL.

[rust-timer]

Finished benchmarking try commit (572ac0ed693592bcc032c44e9272d9dd52db6385): 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 label: +S-waiting-on-review -S-waiting-on-perf

[tmandry]

A couple of incremental configurations regressed. I'd be willing to land the change with this if we had no clear path to improving the results, but I suspect that making to_symbol a query for in-memory caching would make a significant improvement for cases where the same MIR gets monomorphized many times.

@lrh2000 Would you be able to make to_symbol wrap a query? If not I can. We can do another perf run then and compare.

[tmandry]

The code comments I just left should also have a significant impact. EDIT: I'm wondering if we should try those before adding the complexity of a new query, which can also have some negative effects on perf.

[lrh2000]

@lrh2000 Would you be able to make to_symbol wrap a query? If not I can. We can do another perf run then and compare.

Thanks for your review. Unfortunately, I've got a very busy June, so I do not have time to address the comments before early July. But once I have some free time, I am willing to address them.

Sorry for the delay. (And if you want to push some new commits, feel free to do that.)

[lrh2000]

@rustbot ready
I think now we should check the pref results again?

[rustbot]

@tmandry

[tmandry]

@bors try
@rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit cf5eda1 with merge f262e7955412a89f47cbb17eb9b2d1332e30a8fa...

[bors]

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

[rust-timer]

Queued f262e7955412a89f47cbb17eb9b2d1332e30a8fa with parent 5ad7389, future comparison URL.

[tmandry]

Not sure what happened.
@rust-timer queue

[tmandry]

@rust-timer build f262e7955412a89f47cbb17eb9b2d1332e30a8fa

[rust-timer]

Queued f262e7955412a89f47cbb17eb9b2d1332e30a8fa with parent 5ad7389, future comparison URL.

[tmandry]

Code looks good, just awaiting perf results!

[rust-timer]

Finished benchmarking try commit (f262e7955412a89f47cbb17eb9b2d1332e30a8fa): comparison url.

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

• Small improvement in instruction counts (up to -0.6% on incr-unchanged builds of coercions)
• Large regression in instruction counts (up to 4.7% on incr-patched: println builds of webrender-wrench)

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

[tmandry]

So adding the query did improve things quite a bit overall, though not by much on the biggest regression. I'm a little surprised and concerned about why that one benchmark regresses so much, but debuginfo can be huge so maybe it's not that surprising. And there are many more (small) improvements than regressions now.

This does improve debuginfo significantly so I'd say the regression is probably justified.

@rustbot label: +perf-regression-triaged
@bors r+

Thanks for your work on this!

[bors]

📌 Commit cf5eda1 has been approved by tmandry

[bors]

⌛ Testing commit cf5eda1 with merge 99efc51...

[bors]

☀️ Test successful - checks-actions
Approved by: tmandry
Pushing 99efc51 to master...