about summary refs log tree commit diff
path: root/tests/coverage
AgeCommit message (Collapse)AuthorLines
2023-12-20coverage: Add a test for `async` blocksZalathar-0/+104
We have coverage tests that use async functions, but none that use async blocks.
2023-12-18Rollup merge of #118852 - Zalathar:no-spans, r=cjgillotMatthias Krüger-0/+67
coverage: Skip instrumenting a function if no spans were extracted from MIR The immediate symptoms of #118643 were fixed by #118666, but some users reported that their builds now encounter another coverage-related ICE: ``` error: internal compiler error: compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs:98:17: A used function should have had coverage mapping data but did not: (...) ``` I was able to reproduce at least one cause of this error: if no relevant spans could be extracted from a function, but the function contains `CoverageKind::SpanMarker` statements, then codegen still thinks the function is instrumented and complains about the fact that it has no coverage spans. This PR prevents that from happening in two ways: - If we didn't extract any relevant spans from MIR, skip instrumenting the entire function and don't create a `FunctionCoverateInfo` for it. - If coverage codegen sees a `CoverageKind::SpanMarker` statement, skip it early and avoid creating `func_coverage`. --- Fixes #118850.
2023-12-16coverage: Regression test for `assert!(!false)`Zalathar-0/+39
2023-12-16coverage: Regression test for markers in a function with no spansZalathar-0/+67
2023-12-15coverage: Use `Waker::noop` in async testsZalathar-354/+135
2023-12-09Rollup merge of #118666 - Zalathar:body-closure, r=cjgillotJubilee-0/+67
coverage: Simplify the heuristic for ignoring `async fn` return spans The code for extracting coverage spans from MIR has a special heuristic for dealing with `async fn`, so that the function's closing brace does not have a confusing double count. The code implementing that heuristic is currently mixed in with the code for flushing remaining spans after the main refinement loop, making the refinement code harder to understand. We can solve that by hoisting the heuristic to an earlier stage, after the spans have been extracted and sorted but before they have been processed by the refinement loop. The coverage tests verify that the heuristic is still effective, so coverage mappings/reports for `async fn` have not changed. --- This PR also has the side-effect of fixing the `None some_prev` panic that started appearing after #118525. The old code assumed that `prev` would always be present after the refinement loop. That was only true if the list of collected spans was non-empty, but prior to #118525 that didn't seem to come up in practice. After that change, the list of collected spans could be empty in some specific circumstances, leading to panics. The new code uses an `if let` to inspect `prev`, which correctly does nothing if there is no span present.
2023-12-08coverage: Regression test for unwrapping `prev` when there are no spansZalathar-0/+67
2023-12-08coverage: Use `SpanMarker` to mark the full condition of `if !`Zalathar-12/+12
When MIR is built for an if-not expression, the `!` part of the condition doesn't correspond to any MIR statement, so coverage instrumentation normally can't see it. We can fix that by deliberately injecting a dummy statement whose sole purpose is to associate that span with its enclosing block.
2023-12-08coverage: Add a dedicated test for coverage of `if !`Zalathar-0/+114
2023-12-03coverage: Skip spans that can't be un-expanded back to the function bodyZalathar-23/+23
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.
2023-11-30Auto merge of #118036 - DianQK:thinlto-tests, r=tmiaskobors-0/+17
Add thinlto support to codegen, assembly and coverage tests Using `--emit=llvm-ir` with thinlto usually result in multiple IR files. Resolve test case failure issue reported in #113923.
2023-11-30Add thinlto support to codegen, assembly and coverage testsDianQK-0/+17
2023-11-25coverage: Simplify building coverage expressions based on sumsZalathar-100/+100
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.
2023-11-13coverage: Regression test for #117788Zalathar-0/+90
Without the workaround applied, this test will produce malformed mappings that cause `llvm-cov` to fail. (And if it does emit well-formed mappings, they should be obviously incorrect.)
2023-11-08coverage: Rename the `run-coverage` test mode to `coverage-run`Zalathar-3/+3
This makes it more consistent with the `coverage-map` mode and the shared `tests/coverage` test directory.
2023-11-07coverage: Register `test::Coverage` as the test suite for `tests/coverage`Zalathar-7/+10
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.
2023-11-07coverage: Migrate `tests/coverage-map` into `tests/coverage`Zalathar-0/+3745
2023-11-07coverage: Migrate `tests/run-coverage` into `tests/coverage`Zalathar-0/+5849