1
Fork 0

coverage: Register test::Coverage as the test suite for tests/coverage

This restores the ability to run a coverage test by specifying its path, e.g.
`./x.py test tests/coverage/if.rs`. This runs the test in both modes.
This commit is contained in:
Zalathar 2023-11-01 21:07:07 +11:00
parent 49127c64d6
commit 4e6f438d2a
2 changed files with 12 additions and 8 deletions

View file

@ -1423,7 +1423,7 @@ impl Step for Coverage {
const ONLY_HOSTS: bool = false;
fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> {
run.alias(Self::SUITE)
run.suite_path(Self::PATH)
}
fn make_run(run: RunConfig<'_>) {
@ -1438,6 +1438,7 @@ impl Step for Coverage {
}
}
// Aliases for running the coverage tests in only one mode.
coverage_test_alias!(CoverageMap {
alias_and_mode: "coverage-map",
default: true,

View file

@ -1,13 +1,16 @@
Many of these tests were copied from `tests/run-coverage` in order to
capture the current behavior of the instrumentor on non-trivial programs.
The actual mappings have not been closely inspected.
The tests in this directory are shared by two different test modes, and can be
run in multiple different ways:
- `./x.py test coverage-map` (compiles to LLVM IR and checks coverage mappings)
- `./x.py test run-coverage` (runs a test binary and checks its coverage report)
- `./x.py test coverage` (runs both `coverage-map` and `run-coverage`)
## Maintenance note
These tests can be sensitive to small changes in MIR spans or MIR control flow,
especially in HIR-to-MIR lowering or MIR optimizations.
If you haven't touched the coverage code directly, and the `run-coverage` test
suite still works, then it should usually be OK to just `--bless` these
coverage mapping tests as necessary, without worrying too much about the exact
changes.
If you haven't touched the coverage code directly, and the tests still pass in
`run-coverage` mode, then it should usually be OK to just re-bless the mappings
as necessary with `./x.py test coverage-map --bless`, without worrying too much
about the exact changes.