coverage: Skip instrumenting a function if no spans were extracted from MIR #118852
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @b-naber (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
@rustbot label +A-code-coverage |
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot
added
the
A-code-coverage
|
Another thing I tried was having the However, that doesn't work because |
|
Either of the patches should fix the issue on their own, but I think they're both worthwhile. (If we skip instrumenting a function with no spans, then the function won't have |
Zalathar
force-pushed
the
no-spans
branch
3 times, most recently
from
5779766 to
9884e13
Compare
Coverage marker statements should have no effect on codegen, but in some cases they could have the side-effect of creating a `func_coverage` entry for their enclosing function. That can lead to an ICE for functions that don't actually have any coverage spans.
Swatinem
approved these changes
Dec 17, 2023
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 18, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#118852 (coverage: Skip instrumenting a function if no spans were extracted from MIR) - rust-lang#118905 ([AIX] Fix XCOFF metadata) - rust-lang#118967 (Add better ICE messages for some undescriptive panics) - rust-lang#119051 (Replace `FileAllocationInfo` with `FileEndOfFileInfo`) - rust-lang#119059 (Deny `~const` trait bounds in inherent impl headers) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 18, 2023
Rollup merge of rust-lang#118852 - Zalathar:no-spans, r=cjgillot coverage: Skip instrumenting a function if no spans were extracted from MIR The immediate symptoms of rust-lang#118643 were fixed by rust-lang#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 rust-lang#118850.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The immediate symptoms of #118643 were fixed by #118666, but some users reported that their builds now encounter another coverage-related ICE:
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::SpanMarkerstatements, 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:
FunctionCoverateInfofor it.CoverageKind::SpanMarkerstatement, skip it early and avoid creatingfunc_coverage.Fixes #118850.