simplify MoveDataBuilder::move_path_for with new UnDerefer::co_iter_projections

[beepster4096]

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

Split off an old design of #160780

MoveDataBuilder::move_path_for has been kind of messy since Derefer was moved before drop elaboration because of borrowck problems with the UnDerefer::iter_projections iterator. This PR adds co_iter_projections, returning a ProjectionCoroutine which takes a &UnDerefer for each iteration. Now, move_path_for doesn't have an outlined copy of add_move_path anymore which is a lot nicer.

Since my other PR doesn't need this anymore, if its a perf regression I'll probably just close the PR.

Issues:

• Is it a major perf regression from re-accessing the hashmap??
  • At least should be identical for places that don't have derefs in the middle
• I'm not sure if co_iter_projections is the best name

Possible alternatives:

• mem::take on self.data.rev_lookup.un_derefer?

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 19 candidates

[oli-obk]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 4b2ccee (4b2cceeb3582c4d14d590362948999e3c2e578ed)
Base parent: 93c9086 (93c9086fdd5b80d286480a19ac047746ecc5fa1f)

[rust-timer]

Finished benchmarking commit (4b2ccee): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.2%	[0.1%, 0.2%]	7
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	0.2%	[0.1%, 0.2%]	7

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (primary -4.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)	-	-	0
Improvements ✅ (primary)	-4.1%	[-4.1%, -4.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-4.1%	[-4.1%, -4.1%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 455.615s -> 459.565s (0.87%)
Artifact size: 396.47 MiB -> 396.37 MiB (-0.02%)

[oli-obk]

Since my other PR doesn't need this anymore, if its a perf regression I'll probably just close the PR.

so 😆 are we closing it or should I actually review it?

[beepster4096]

Oh yeah, sorry. Just gonna close it for now.