Skip to content

Commit 25b615e

Browse files
committed
coverage: Assert that bcb0 starts with bb0 and has no in-edges
This explains why we don't have to worry about bcb0 having multiple in-edges.
1 parent 0b7a7c9 commit 25b615e

File tree

1 file changed

+13
-0
lines changed
  • compiler/rustc_mir_transform/src/coverage

1 file changed

+13
-0
lines changed

compiler/rustc_mir_transform/src/coverage/graph.rs

+13
Original file line numberDiff line numberDiff line change
@@ -62,6 +62,14 @@ impl CoverageGraph {
6262
Self { bcbs, bb_to_bcb, successors, predecessors, dominators: None };
6363
let dominators = dominators::dominators(&basic_coverage_blocks);
6464
basic_coverage_blocks.dominators = Some(dominators);
65+
66+
// The coverage graph's entry-point node (bcb0) always starts with bb0,
67+
// which never has predecessors. Any other blocks merged into bcb0 can't
68+
// have multiple (coverage-relevant) predecessors, so bcb0 always has
69+
// zero in-edges.
70+
assert!(basic_coverage_blocks[START_BCB].leader_bb() == mir::START_BLOCK);
71+
assert!(basic_coverage_blocks.predecessors[START_BCB].is_empty());
72+
6573
basic_coverage_blocks
6674
}
6775

@@ -211,6 +219,11 @@ impl CoverageGraph {
211219
/// FIXME: That assumption might not be true for [`TerminatorKind::Yield`]?
212220
#[inline(always)]
213221
pub(super) fn bcb_has_multiple_in_edges(&self, bcb: BasicCoverageBlock) -> bool {
222+
// Even though bcb0 conceptually has an extra virtual in-edge due to
223+
// being the entry point, we've already asserted that it has no _other_
224+
// in-edges, so there's no possibility of it having _multiple_ in-edges.
225+
// (And since its virtual in-edge doesn't exist in the graph, that edge
226+
// can't have a separate counter anyway.)
214227
self.predecessors[bcb].len() > 1
215228
}
216229
}

0 commit comments

Comments
 (0)