Resolve infinite_loop FP for nested loops

[mikhailofff]

Fixes #16134.

changelog: [infinite_loop]: look thoroughly the case when there are nested loops that cannot be infinite, because there is a break statement that interrupts another loop that takes up space above.

[rustbot]

r? @samueltardieu

rustbot has assigned @samueltardieu.
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: 7 candidates
• 7 candidates expanded to 7 candidates
• Random selection from Jarcho, dswij, llogiq, samueltardieu

[rustbot]

This PR was rebased onto a different master 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.

[samueltardieu]

break and continue have a field of type Destination which contains the HirId of the target of the break or continue. Can't you use that instead of labels to match the various blocks and loops that can be the target of the break?

@rustbot author

View changes since this review

[rustbot]

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

[mikhailofff]

Thanks for the review. I actually had this in mind. The use of potential_breaks in LoopVisitor is necessary to store the break statements that may terminate the original loop if it points to a loop that precedes the original loop. If the target_id only points to the loop that will actually be terminated by the break, then everything is fine. I hope.