This is a way to shrink call spans that doesn't involve mixing different spans,
and avoids overlap with argument spans.
This patch also removes some low-value comments that were causing rustfmt to
ignore the match arms.
This test is intended to demonstrate that a particular macro-argument span
doesn't get lost during span-refinement, but it turns out that span-extraction
currently doesn't yield any MIR spans for this position.
This patch therefore tweaks the test to add a function call in that position,
so that it still remains relevant to span refinement.
When preparing a function's coverage counters and metadata during codegen, any
part of the original coverage graph that was removed by MIR optimizations can
be treated as having an execution count of zero.
Somewhat counter-intuitively, if we give those unreachable nodes a _higher_
priority for receiving physical counters (instead of counter expressions), that
ends up reducing the total number of physical counters needed.
This works because if a node is unreachable, we don't actually create a
physical counter for it. Instead that node gets a fixed zero counter, and any
other node that would have relied on that physical counter in its counter
expression can just ignore that term completely.
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
coverage: Dismantle `map_data.rs` by moving its responsibilities elsewhere
This is a series of incremental changes that combine to let us get rid of `coverageinfo/map_data.rs`, by moving all of its responsibilities into more appropriate places.
Some of the notable consequences are:
- We once again build the per-CGU file table on the fly while preparing individual covfun records, instead of building the whole table up-front. The up-front approach was introduced by #117042 to work around various other problems in generating the covmap/covfun records, but subsequent cleanups have made that approach no longer necessary.
- Expression conversion and mapping-region conversion are now performed directly in `mapgen::covfun`, which should make future changes easier.
- We no longer insert unused function instances into the same map that is also used to track used function instances. This helps to decouple the handling of used vs unused functions.
---
There should be no meaningful change to compiler output. The file table is no longer sorted, because reordering it would invalidate the file indices stored in individual covfun records, but the table order should still be deterministic (albeit arbitrary).
There are some subsequent cleanups that I intend to investigate, but this is enough change for one PR.
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.)
This hack was intended to handle the case where `-Clto=thin` causes the
compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack
itself. The one remaining test that motivated the hack currently doesn't even
need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
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.
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. A future commit will
fix this and update the test to reflect the new behavior.
Disable the tests and generate an error if MC/DC is used on LLVM 19.
The support will be ported separately, as it is substantially
different on LLVM 19, and there are no plans to support both
versions.
