Struct rustc_mir_transform::coverage::spans::SpansRefiner

struct SpansRefiner<'a> {
    basic_coverage_blocks: &'a CoverageGraph,
    sorted_spans_iter: IntoIter<SpanFromMir>,
    some_curr: Option<CurrCovspan>,
    some_prev: Option<PrevCovspan>,
    pending_dups: Vec<DuplicateCovspan>,
    refined_spans: Vec<RefinedCovspan>,
}

Converts the initial set of coverage spans (one per MIR Statement or Terminator) into a minimal set of coverage spans, using the BCB CFG to determine where it is safe and useful to:

• Remove duplicate source code coverage regions
• Merge spans that represent continuous (both in source code and control flow), non-branching execution
• Carve out (leave uncovered) any span that will be counted by another MIR (notably, closures)

Fields

basic_coverage_blocks: &'a CoverageGraph

The BasicCoverageBlock Control Flow Graph (BCB CFG).

sorted_spans_iter: IntoIter<SpanFromMir>

The initial set of coverage spans, sorted by Span (lo and hi) and by relative dominance between the BasicCoverageBlocks of equal Spans.

some_curr: Option<CurrCovspan>

The current coverage span to compare to its prev, to possibly merge, discard, force the discard of the prev (and or pending_dups), or keep both (with prev moved to pending_dups). If curr is not discarded or merged, it becomes prev for the next iteration.

some_prev: Option<PrevCovspan>

The coverage span from a prior iteration; typically assigned from that iteration’s curr. If that curr was discarded, prev retains its value from the previous iteration.

pending_dups: Vec<DuplicateCovspan>

One or more coverage spans with the same Span but different BasicCoverageBlocks, and no BasicCoverageBlock in this list dominates another BasicCoverageBlock in the list. If a new curr span also fits this criteria (compared to an existing list of pending_dups), that curr moves to prev before possibly being added to the pending_dups list, on the next iteration. As a result, if prev and pending_dups have the same Span, the criteria for pending_dups holds for prev as well: a prev with a matching Span does not dominate any pending_dup and no pending_dup dominates a prev with a matching Span)

refined_spans: Vec<RefinedCovspan>

The final coverage spans to add to the coverage map. A Counter or Expression will also be injected into the MIR for each BCB that has associated spans.

Implementations

impl<'a> SpansRefiner<'a>

fn refine_sorted_spans( basic_coverage_blocks: &'a CoverageGraph, sorted_spans: Vec<SpanFromMir> ) -> Vec<RefinedCovspan>

Takes the initial list of (sorted) spans extracted from MIR, and “refines” them by merging compatible adjacent spans, removing redundant spans, and carving holes in spans when they overlap in unwanted ways.

fn to_refined_spans(self) -> Vec<RefinedCovspan>

Iterate through the sorted coverage spans, and return the refined list of merged and de-duplicated spans.

fn curr(&self) -> &CurrCovspan

fn take_curr(&mut self) -> CurrCovspan

If called, then the next call to next_coverage_span() will not update prev with the curr coverage span.

fn prev(&self) -> &PrevCovspan

fn prev_mut(&mut self) -> &mut PrevCovspan

fn take_prev(&mut self) -> PrevCovspan

fn maybe_flush_pending_dups(&mut self)

If there are pending_dups but prev is not a matching dup (prev.span doesn’t match the pending_dups spans), then one of the following two things happened during the previous iteration:

• the previous curr span (which is now prev) was not a duplicate of the pending_dups (in which case there should be at least two spans in pending_dups); or
• the span of prev was modified by curr_mut().merge_from(prev) (in which case pending_dups could have as few as one span) In either case, no more spans will match the span of pending_dups, so add the pending_dups if they don’t overlap curr, and clear the list.

fn next_coverage_span(&mut self) -> bool

Advance prev to curr (if any), and curr to the next coverage span in sorted order.

fn carve_out_span_for_closure(&mut self)

If prevs span extends left of the closure (curr), carve out the closure’s span from prev’s span. (The closure’s coverage counters will be injected when processing the closure’s own MIR.) Add the portion of the span to the left of the closure; and if the span extends to the right of the closure, update prev to that portion of the span. For any pending_dups, repeat the same process.

fn update_pending_dups(&mut self)

Called if curr.span equals prev.original_span (and potentially equal to all pending_dups spans, if any). Keep in mind, prev.span() may have been changed. If prev.span() was merged into other spans (with matching BCB, for instance), prev.span.hi() will be greater than (further right of) prev.original_span.hi(). If prev.span() was split off to the right of a closure, prev.span().lo() will be greater than prev.original_span.lo(). The actual span of prev.original_span is not as important as knowing that prev() used to have the same span as curr(), which means their sort order is still meaningful for determining the dominator relationship.

When two coverage spans have the same Span, dominated spans can be discarded; but if neither coverage span dominates the other, both (or possibly more than two) are held, until their disposition is determined. In this latter case, the prev dup is moved into pending_dups so the new curr dup can be moved to prev for the next iteration.

fn cutoff_prev_at_overlapping_curr(&mut self)

curr overlaps prev. If prevs span extends left of currs span, keep only statements that end before curr.lo() (if any), and add the portion of the combined span for those statements. Any other statements have overlapping spans that can be ignored because curr and/or other upcoming statements/spans inside the overlap area will produce their own counters. This disambiguation process avoids injecting multiple counters for overlapping spans, and the potential for double-counting.

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 152 bytes