| Age | Commit message (Collapse) | Author | Lines |
|---|
|
when func itself is monomorphized
|
|
This also removes some manipulation of the function signature span that only
made sense in the context of merging non-adjacent spans.
|
|
|
|
|
|
r=wesleywiser"
This reverts commit 1d35638dc38dbfbf1cc2a9823135dfcf3c650169, reversing
changes made to f23a80a4c2fbca593b64e70f5970368824b4c5e9.
|
|
|
|
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
|
|
|
|
When making changes that have a large impact on coverage counter creation, this
makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as
the number of physical counters actually used by the instrumented code, but
it's the best approximation we can get from looking only at the coverage maps,
and it should be reasonably accurate in most cases.)
|
|
By moving `block_on` to an auxiliary crate, we avoid having to keep a separate
copy of it in every async test.
(This also incorporates some small tweaks to the headers in `await_ready.rs`.)
|
|
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.
By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.
|
|
This makes it possible to treat more kinds of nested item/code as holes,
instead of being restricted to closures.
|
|
Some of these cases currently don't occur in practice, but are included for
completeness, and to avoid having to add them later as branch coverage and
MC/DC coverage start building more complex expressions.
|
|
These tests deliberately use non-standard formatting, so that the line
execution counts reported by `llvm-cov` reveal additional information about
where code regions begin and end.
|
|
|
|
When we extract coverage spans from MIR, we try to "un-expand" them back to
spans that are inside the function's body span.
In cases where that doesn't succeed, the current code just swaps in the entire
body span instead. But that tends to result in coverage spans that are
completely unrelated to the control flow of the affected code, so it's better
to just discard those spans.
|
|
In some cases we need to prepare a coverage expression that is the sum of an
arbitrary number of other terms. This patch simplifies the code paths that
build those sums.
This causes some churn in the mappings, because the previous code was building
its sums in a somewhat idiosyncratic order.
|
|
|
