Tools, tests, and experimenting with MIR-derived coverage counters

[richkadel]

Leverages the new mir_dump output file in HTML+CSS (from #76074) to visualize coverage code regions
and the MIR features that they came from (including overlapping spans).

See example below.

The run-make-fulldeps/instrument-coverage test has been refactored to maximize test coverage and reduce code duplication. The new tests support testing with and without -Clink-dead-code, so Rust coverage can be tested on MSVC (which, currently, only works with link-dead-code disabled).

New tests validate coverage region generation and coverage reports with multiple counters per function. Starting with a simple if-else branch tests, coverage tests for each additional syntax type can be added by simply dropping in a new Rust sample program.

Includes a basic, MIR-block-based implementation of coverage injection,
available via -Zexperimental-coverage. This implementation has known
flaws and omissions, but is simple enough to validate the new tools and
tests.

The existing -Zinstrument-coverage option currently enables
function-level coverage only, which at least appears to generate
accurate coverage reports at that level.

Experimental coverage is not accurate at this time. When branch coverage
works as intended, the -Zexperimental-coverage option should be
removed.

This PR replaces the bulk of PR #75828, with the remaining parts of
that PR distributed among other separate and indentpent PRs.

This PR depends on two of those other PRs: #76002, #76003 and #76074

Rust compiler MCP rust-lang/compiler-team#278

Relevant issue: #34701 - Implement support for LLVMs code coverage
instrumentation

r? @tmandry
FYI: @wesleywiser

[richkadel]

@tmandry @wesleywiser - Note there are 3 commits in this PR but two of them are cherry-picked from PRs: #76002 and #76003.

So check out the last commit for the changes specific to this PR.

Note that most of the files are in the refactored tests and test data. The actual source changes here are much smaller than the number of "files changed" might indicate.

[richkadel]

I had to update my comments on this PR regarding the PRs this depends on. Sorry.

Actually, they are #76002 and #76003.

[tmandry]

Is there a reason not to split the tooling out from the changes to coverage instrumentation?

The tests for the HTML have a lot of duplicated content. Can we test that output only once? We don't have to cover every case for that since it's not an end user thing (I think we have a single empty-main test for the graphviz output for instance; it mostly tests that the wiring for the feature is working).

[richkadel]

Is there a reason not to split the tooling out from the changes to coverage instrumentation?

I'm looking into this. If there is something reasonable that I can split out, I'll do it. If I don't see a good way to split it up without consequences, I'll explain my thinking.

[richkadel]

The tests for the HTML have a lot of duplicated content.

As mentioned in sidebar conversation, I realized that there were several testprog related expected and typical test results left over from when testprog was included in the common test sources in test/run-make-fulldeps/instrument_covarege/.

With --bless, the Makefile was rebuilding the expected/typical results for known test sources (there is only one right now: coverage_of_if_else.rs but the Makefile wasn't smart enough to delete old results from test sources no longer present.

I improved the Makefiles to wipe out expected results (on --bless) based on a wildcard instead of doing it for each known test, and this removed those "extra" results that are no longer used.

I went ahead and pushed the changes to this PR, so it no longer includes files that it shouldn't.

[richkadel]

@tmandry said:

Is there a reason not to split the tooling out from the changes to coverage instrumentation?

Check out what I did with the new commit and see if this helps mitigate your concern.

It's possible to split these into separate commits, but the reason I didn't do it originally (which still holds true), is the refactored tests depend on changes to both InstrumentCoverage and the new file format.

[richkadel]

It's possible to split these into separate commits

I decided to do that after all. See PR #76074, which has only the new spanview document generation capability (and API to be used by this PR).

PR #76074 also adds mir-opt tests for the feature that mirror the simple test for graphviz.

I'll update this PR to depend on PR #76074.

[bors]

☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts.

[richkadel]

@tmandry @wesleywiser - rebased after the last dependency just landed.

This PR should be ready for bors.

Thanks!

[richkadel]

@tmandry - I addressed your feedback. This should be good to go I believe.

[richkadel]

@tmandry @wesleywiser - I have tested things locally, including with MSVC on Windows.

But since this is the first time running this new refactored test framework, including the special cases for MSVC, I recommend "rollup never".

[tmandry]

@bors r+ rollup=never

[bors]

📌 Commit 51d692c has been approved by tmandry

[bors]

⌛ Testing commit 51d692c with merge 4ffb5c5...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: tmandry
Pushing 4ffb5c5 to master...