Change:
<ins> Function name: let_else_loop::_if (unused) Raw bytes (19): 0x[01, 01, 00, 03, 00, 16, 01, 01, 0c, 00, 02, 09, 00, 10, 00, 02, 09, 00, 10] Number of files: 1 - file 0 => global file 1 Number of expressions: 0 Number of file 0 mappings: 3 - Code(Zero) at (prev + 22, 1) to (start + 1, 12) - Code(Zero) at (prev + 2, 9) to (start + 0, 16) - Code(Zero) at (prev + 2, 9) to (start + 0, 16) Function name: let_else_loop::_loop_either_way (unused) Raw bytes (19): 0x[01, 01, 00, 03, 00, 0f, 01, 01, 14, 00, 01, 1c, 00, 23, 00, 01, 05, 00, 0c] Number of files: 1 - file 0 => global file 1 Number of expressions: 0 Number of file 0 mappings: 3 - Code(Zero) at (prev + 15, 1) to (start + 1, 20) - Code(Zero) at (prev + 1, 28) to (start + 0, 35) - Code(Zero) at (prev + 1, 5) to (start + 0, 12) Function name: let_else_loop::loopy Raw bytes (19): 0x[01, 01, 00, 03, 01, 09, 01, 01, 14, 00, 01, 1c, 00, 23, 05, 01, 01, 00, 02] Number of files: 1 - file 0 => global file 1 Number of expressions: 0 Number of file 0 mappings: 3 - Code(Counter(0)) at (prev + 9, 1) to (start + 1, 20) - Code(Zero) at (prev + 1, 28) to (start + 0, 35) - Code(Counter(1)) at (prev + 1, 1) to (start + 0, 2) </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.