Skip to content

Commit 7409a52

Browse files
authored
Rollup merge of rust-lang#127707 - Zalathar:expand-until, r=Nadrieril
match lowering: Use an iterator to find `expand_until` A small cleanup that I noticed while looking at rust-lang#127164. This makes it easier to see that the split point is always the index after the found item, or the whole list if no stopping point was found. r? `@Nadrieril`
2 parents 5ee4533 + e37b92f commit 7409a52

File tree

1 file changed

+19
-14
lines changed
  • compiler/rustc_mir_build/src/build/matches

1 file changed

+19
-14
lines changed

compiler/rustc_mir_build/src/build/matches/mod.rs

+19-14
Original file line numberDiff line numberDiff line change
@@ -1547,10 +1547,13 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
15471547
start_block: BasicBlock,
15481548
candidates: &'b mut [&'c mut Candidate<'pat, 'tcx>],
15491549
) -> BlockAnd<&'b mut [&'c mut Candidate<'pat, 'tcx>]> {
1550-
// We can't expand or-patterns freely. The rule is: if the candidate has an
1551-
// or-pattern as its only remaining match pair, we can expand it freely. If it has
1552-
// other match pairs, we can expand it but we can't process more candidates after
1553-
// it.
1550+
// We can't expand or-patterns freely. The rule is:
1551+
// - If a candidate doesn't start with an or-pattern, we include it in
1552+
// the expansion list as-is (i.e. it "expands" to itself).
1553+
// - If a candidate has an or-pattern as its only remaining match pair,
1554+
// we can expand it.
1555+
// - If it starts with an or-pattern but also has other match pairs,
1556+
// we can expand it, but we can't process more candidates after it.
15541557
//
15551558
// If we didn't stop, the `otherwise` cases could get mixed up. E.g. in the
15561559
// following, or-pattern simplification (in `merge_trivial_subcandidates`) makes it
@@ -1567,17 +1570,17 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
15671570
// }
15681571
// ```
15691572
//
1570-
// We therefore split the `candidates` slice in two, expand or-patterns in the first half,
1573+
// We therefore split the `candidates` slice in two, expand or-patterns in the first part,
15711574
// and process the rest separately.
1572-
let mut expand_until = 0;
1573-
for (i, candidate) in candidates.iter().enumerate() {
1574-
expand_until = i + 1;
1575-
if candidate.match_pairs.len() > 1 && candidate.starts_with_or_pattern() {
1576-
// The candidate has an or-pattern as well as more match pairs: we must
1577-
// split the candidates list here.
1578-
break;
1579-
}
1580-
}
1575+
let expand_until = candidates
1576+
.iter()
1577+
.position(|candidate| {
1578+
// If a candidate starts with an or-pattern and has more match pairs,
1579+
// we can expand it, but we must stop expanding _after_ it.
1580+
candidate.match_pairs.len() > 1 && candidate.starts_with_or_pattern()
1581+
})
1582+
.map(|pos| pos + 1) // Stop _after_ the found candidate
1583+
.unwrap_or(candidates.len()); // Otherwise, include all candidates
15811584
let (candidates_to_expand, remaining_candidates) = candidates.split_at_mut(expand_until);
15821585

15831586
// Expand one level of or-patterns for each candidate in `candidates_to_expand`.
@@ -1592,6 +1595,8 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
15921595
expanded_candidates.push(subcandidate);
15931596
}
15941597
} else {
1598+
// A candidate that doesn't start with an or-pattern has nothing to
1599+
// expand, so it is included in the post-expansion list as-is.
15951600
expanded_candidates.push(candidate);
15961601
}
15971602
}

0 commit comments

Comments
 (0)