Skip to content

Commit 32aa635

Browse files
committed
coverage: Hoist the removal of unwanted macro expansion spans
1 parent 6fe8067 commit 32aa635

File tree

2 files changed

+27
-26
lines changed

2 files changed

+27
-26
lines changed

compiler/rustc_mir_transform/src/coverage/spans.rs

Lines changed: 3 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -246,32 +246,9 @@ impl<'a> CoverageSpansGenerator<'a> {
246246
} else if curr.is_closure {
247247
self.carve_out_span_for_closure();
248248
} else if self.prev_original_span == curr.span {
249-
// Note that this compares the new (`curr`) span to `prev_original_span`.
250-
// In this branch, the actual span byte range of `prev_original_span` is not
251-
// important. What is important is knowing whether the new `curr` span was
252-
// **originally** the same as the original span of `prev()`. The original spans
253-
// reflect their original sort order, and for equal spans, conveys a partial
254-
// ordering based on CFG dominator priority.
255-
if prev.visible_macro.is_some() && curr.visible_macro.is_some() {
256-
// Macros that expand to include branching (such as
257-
// `assert_eq!()`, `assert_ne!()`, `info!()`, `debug!()`, or
258-
// `trace!()`) typically generate callee spans with identical
259-
// ranges (typically the full span of the macro) for all
260-
// `BasicBlocks`. This makes it impossible to distinguish
261-
// the condition (`if val1 != val2`) from the optional
262-
// branched statements (such as the call to `panic!()` on
263-
// assert failure). In this case it is better (or less
264-
// worse) to drop the optional branch bcbs and keep the
265-
// non-conditional statements, to count when reached.
266-
debug!(
267-
" curr and prev are part of a macro expansion, and curr has the same span \
268-
as prev, but is in a different bcb. Drop curr and keep prev for next iter. \
269-
prev={prev:?}",
270-
);
271-
self.take_curr(); // Discards curr.
272-
} else {
273-
self.update_pending_dups();
274-
}
249+
// `prev` and `curr` have the same span, or would have had the
250+
// same span before `prev` was modified by other spans.
251+
self.update_pending_dups();
275252
} else {
276253
self.cutoff_prev_at_overlapping_curr();
277254
self.maybe_push_macro_name_span();

compiler/rustc_mir_transform/src/coverage/spans/from_mir.rs

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,5 @@
11
use rustc_data_structures::captures::Captures;
2+
use rustc_data_structures::fx::FxHashSet;
23
use rustc_middle::mir::{
34
self, AggregateKind, FakeReadCause, Rvalue, Statement, StatementKind, Terminator,
45
TerminatorKind,
@@ -35,6 +36,9 @@ pub(super) fn mir_to_initial_sorted_coverage_spans(
3536
}
3637
}
3738

39+
initial_spans.sort_by(|a, b| basic_coverage_blocks.cmp_in_dominator_order(a.bcb, b.bcb));
40+
remove_unwanted_macro_spans(&mut initial_spans);
41+
3842
initial_spans.sort_by(|a, b| {
3943
// First sort by span start.
4044
Ord::cmp(&a.span.lo(), &b.span.lo())
@@ -55,6 +59,26 @@ pub(super) fn mir_to_initial_sorted_coverage_spans(
5559
initial_spans
5660
}
5761

62+
/// Macros that expand into branches (e.g. `assert!`, `trace!`) tend to generate
63+
/// multiple condition/consequent blocks that have the span of the whole macro
64+
/// invocation, which is unhelpful. Keeping only the first such span seems to
65+
/// give better mappings, so remove the others.
66+
///
67+
/// (The input spans should be sorted in BCB dominator order, so that the
68+
/// retained "first" span is likely to dominate the others.)
69+
fn remove_unwanted_macro_spans(initial_spans: &mut Vec<CoverageSpan>) {
70+
let mut seen_macro_spans = FxHashSet::default();
71+
initial_spans.retain(|covspan| {
72+
// Ignore (retain) closure spans and non-macro-expansion spans.
73+
if covspan.is_closure || covspan.visible_macro.is_none() {
74+
return true;
75+
}
76+
77+
// Retain only the first macro-expanded covspan with this span.
78+
seen_macro_spans.insert(covspan.span)
79+
});
80+
}
81+
5882
// Generate a set of `CoverageSpan`s from the filtered set of `Statement`s and `Terminator`s of
5983
// the `BasicBlock`(s) in the given `BasicCoverageBlockData`. One `CoverageSpan` is generated
6084
// for each `Statement` and `Terminator`. (Note that subsequent stages of coverage analysis will

0 commit comments

Comments
 (0)