Change:
<ins> LL|       |#![feature(coverage_attribute)] LL|       |//@ edition: 2021 LL|       | LL|       |// Regression test for <https://github.com/rust-lang/rust/issues/122738>. LL|       |// These code patterns should not trigger an ICE when allocating a physical LL|       |// counter to a node and also one of its in-edges, because that is allowed LL|       |// when the node contains a tight loop to itself. LL|       | LL|      1|fn loopy(cond: bool) { LL|      1|    let true = cond else { loop {} }; ^0 LL|      1|} LL|       | LL|       |// Variant that also has `loop {}` on the success path. LL|       |// This isn't needed to catch the original ICE, but might help detect regressions. LL|      0|fn _loop_either_way(cond: bool) { LL|      0|    let true = cond else { loop {} }; LL|      0|    loop {} LL|       |} LL|       | LL|       |// Variant using regular `if` instead of let-else. LL|       |// This doesn't trigger the original ICE, but might help detect regressions. LL|      0|fn _if(cond: bool) { LL|      0|    if cond { LL|      0|        loop {} LL|       |    } else { LL|      0|        loop {} LL|       |    } LL|       |} LL|       | LL|       |#[coverage(off)] LL|       |fn main() { LL|       |    loopy(true); LL|       |} </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.