-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coverage instrumentation of unit tests also instruments a closure added by #[test]
#120046
Comments
@rustbot label +A-code-coverage In theory the correct way to handle this is to have the builtin Another less-pleasing but more immediately practical option would be to have better heuristics that would detect and discard this sort of closure. The trick is finding something that does the job without also negatively impacting real user code that uses macros. |
…errors Add `#[coverage(off)]` to closures introduced by `#[test]` and `#[bench]` These closures are an internal implementation detail of the `#[test]` and `#[bench]` attribute macros, so from a user perspective there is no reason to instrument them for coverage. Skipping them makes coverage reports slightly cleaner, and will also allow other changes to span processing during coverage instrumentation, without having to worry about how they affect the `#[test]` macro. The `#[coverage(off)]` attribute has no effect when `-Cinstrument-coverage` is not used. Fixes rust-lang#120046. --- Note that this PR has no effect on the user-written function that has the `#[test]` attribute attached to it. That function will still be instrumented as normal.
…errors Add `#[coverage(off)]` to closures introduced by `#[test]` and `#[bench]` These closures are an internal implementation detail of the `#[test]` and `#[bench]` attribute macros, so from a user perspective there is no reason to instrument them for coverage. Skipping them makes coverage reports slightly cleaner, and will also allow other changes to span processing during coverage instrumentation, without having to worry about how they affect the `#[test]` macro. The `#[coverage(off)]` attribute has no effect when `-Cinstrument-coverage` is not used. Fixes rust-lang#120046. --- Note that this PR has no effect on the user-written function that has the `#[test]` attribute attached to it. That function will still be instrumented as normal.
Rollup merge of rust-lang#120183 - Zalathar:test-closure, r=compiler-errors Add `#[coverage(off)]` to closures introduced by `#[test]` and `#[bench]` These closures are an internal implementation detail of the `#[test]` and `#[bench]` attribute macros, so from a user perspective there is no reason to instrument them for coverage. Skipping them makes coverage reports slightly cleaner, and will also allow other changes to span processing during coverage instrumentation, without having to worry about how they affect the `#[test]` macro. The `#[coverage(off)]` attribute has no effect when `-Cinstrument-coverage` is not used. Fixes rust-lang#120046. --- Note that this PR has no effect on the user-written function that has the `#[test]` attribute attached to it. That function will still be instrumented as normal.
Consider this source file from the coverage test suite:
rust/tests/coverage/test_harness.rs
Lines 9 to 10 in 6bf600b
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 insidemy_test
:rust/tests/coverage/test_harness.cov-map
Lines 9 to 15 in 6bf600b
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.The text was updated successfully, but these errors were encountered: