Simplify for loop desugar

[camsteffen]

Basically two intermediate bindings are inlined. I could have left one intermediate binding in place as this would simplify some diagnostic logic, but I think the difference in that regard would be negligible, so it is better to have a minimal HIR.

For checking that the pattern is irrefutable, I added a special case when the match is found to be non-exhaustive.

The reordering of the arms is purely stylistic. I don't think there are any perf implications.

 match IntoIterator::into_iter($head) {
mut iter => {
$label: loop {
- let mut __next;
match Iterator::next(&mut iter) {
- Some(val) => __next = val,
None => break,
+ Some($pat) => $block,
}
- let $pat = __next;- $block
}
}
}

[rust-highfive]

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[rust-highfive]

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

@bors try @rust-timer queue

[bors]

⌛ Trying commit f91e0b1f918aa3b7f9ad897a742730fe50f5eee4 with merge 52f2d9b64faebfa33ae0fd45fcbf21bdc4154fa1...

[camsteffen]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit b44eed913416e05c2a5f889c4a10d9ab3421e035 with merge 261bc72edbd828cafa27c3450ef92a59b5e7bacb...

[petrochenkov]

@camsteffen
I strongly suggest looking through git history and checking why these bindings were introduced in the first place.
Most likely it was done for a reason, e.g. to extend lifetimes or something like that.

[camsteffen]

@petrochenkov It looks like the key points of history are #42265 and #42634. I think these are workarounds for typeck/borrowck issues that no longer exist, especially with NLL?

[bors]

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

[rust-timer]

Queued 261bc72edbd828cafa27c3450ef92a59b5e7bacb with parent dd757b9, future comparison URL.

[rust-timer]

Finished benchmarking commit (261bc72edbd828cafa27c3450ef92a59b5e7bacb): comparison url.

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

• Very large improvement in instruction counts (up to -6.0% on incr-full builds of clap-rs)
• Large regression in instruction counts (up to 2.6% on full builds of regex)

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 try 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

[cjgillot]

Why is optimized_mir dirty?

[camsteffen]

I don't know. Do you know how to see what changed?

[camsteffen]

Perhaps it's an optimization of

match next {None => break,Some(..) => break,}

[memoryruins]

for's std docs mentions its expansion. Should we update it here as well?

rust/library/std/src/keyword_docs.rs

Line 536 in 85c0558

/// A `for` loop expands as shown:

[camsteffen]

@bors r=oli-obk

[bors]

📌 Commit 21a53d1b1ba896d06534207402885fb93ffd1da9 has been approved by oli-obk

[bors]

⌛ Testing commit 21a53d1b1ba896d06534207402885fb93ffd1da9 with merge 22453953cf17d8d767864fd79f96aeae798d6542...

[bors]

💔 Test failed - checks-actions

[camsteffen]

@bors r=oli-obk

[bors]

📌 Commit 66da8fa has been approved by oli-obk

[bors]

⌛ Testing commit 66da8fa with merge cebd2dd...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing cebd2dd to master...

[rust-timer]

Finished benchmarking commit (cebd2dd): comparison url.

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

• Very large improvement in instruction counts (up to -6.2% on incr-full builds of clap-rs)
• Large regression in instruction counts (up to 2.3% on full builds of regex)

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

[oli-obk]

The regressions seem to all be in -opt builds and solely part of the time spent in LLVM, so I'm hoping it's that more optimizations apply now (and worst case some optimizations require more work but don't result in better code).

@rustbot label: +perf-regression-triaged