Skip to content

Coverage instrumentation of unit tests also instruments a closure added by #[test] #120046

Closed
@Zalathar

Description

@Zalathar

Consider this source file from the coverage test suite:

#[test]
fn my_test() {}

When we instrument this file for coverage, we generate coverage mappings for my_test as expected. However, we also generate coverage mappings for a mysterious closure inside my_test:

Function name: test_harness::my_test::{closure#0}
Raw bytes (9): 0x[01, 01, 00, 01, 01, 09, 01, 00, 08]
Number of files: 1
- file 0 => global file 1
Number of expressions: 0
Number of file 0 mappings: 1
- Code(Counter(0)) at (prev + 9, 1) to (start + 0, 8)

This closure turns out to have been added by the builtin macro that expands #[test] attributes.

Adding coverage instrumentation to this closure is not useful, and we should not be doing it.


Right now this only causes minor problems in the final coverage reports, because coverage for the closure shows up on its own line with the span of the attribute. But while working on some other changes to how we handle macro-expanded closure bodies, I found that some of my changes had the side-effect of causing these test closures to show up and start interfering with the reports.

We should have some way for the coverage instrumentor to know that it should ignore closures introduced by #[test] attributes, and not instrument them at all.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-closuresArea: Closures (`|…| { … }`)A-code-coverageArea: Source-based code coverage (-Cinstrument-coverage)C-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions