coverage: Discard spans that fill the entire function body #121135
Merged
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
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot
added
the
A-code-coverage
When we try to extract coverage-relevant spans from MIR, sometimes we see MIR statements/terminators whose spans cover the entire function body. Those spans tend to be unhelpful for coverage purposes, because they often represent compiler-inserted code, e.g. the implicit return value of `()`.
Zalathar
force-pushed
the
no-whole-body-span
branch
from
300aecb
to
cd9021e
Compare
wesleywiser
approved these changes
Feb 16, 2024
Comment on lines
+137
to
+138
| // Discard any spans that fill the entire body, because they tend | ||
| // to represent compiler-inserted code, e.g. implicitly returning `()`. |
There was a problem hiding this comment.
For some cases like fn foo() { }, I wonder if this heuristic will trigger incorrectly? Since all the changes in the tests are for the better, I'm not super worried about that.
There was a problem hiding this comment.
I thought about adding a special-case to detect functions with a non-empty body span and no extracted spans, in order to explicitly add a span that covers the whole body. But currently it doesn't seem to be necessary, so I haven't bothered.
For fn foo() {}, I believe the way it currently works is that we generate a span for the signature, and there's another zero-width span right at the end of the body (representing the return), and the span refiner then merges those together into something that covers the whole body.
(None of this is ideal, but sadly that's the reality of trying to heuristically extract coverage spans from MIR. Right now I'm happy to be able to make any progress in simplifying the span refiner into something a bit more maintainable.)
bors
added
S-waiting-on-bors
Swatinem
approved these changes
Feb 16, 2024
Nadrieril
added a commit
to Nadrieril/rust
that referenced
this pull request
Feb 17, 2024
…leywiser coverage: Discard spans that fill the entire function body While debugging some other coverage changes, I discovered a frustrating inconsistency that occurs in functions containing closures, if they end with an implicit `()` return instead of an explicit trailing-expression. This turns out to have been caused by the corresponding node in MIR having a span that covers the entire function body. When preparing coverage spans, any span that fills the whole body tends to cause more harm than good, so this PR detects and discards those spans. (This isn't the first time whole-body spans have caused problems; we also eliminated some of them in rust-lang#118525.)
This was referenced Feb 17, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 17, 2024
Rollup of 8 pull requests Successful merges: - rust-lang#119032 (Use a hardcoded constant instead of calling OpenProcessToken.) - rust-lang#120932 (const_mut_refs: allow mutable pointers to statics) - rust-lang#121059 (Add and use a simple extension trait derive macro in the compiler) - rust-lang#121135 (coverage: Discard spans that fill the entire function body) - rust-lang#121187 (Add examples to document the return type of quickselect functions) - rust-lang#121191 (Add myself to review rotation (and a rustbot ping)) - rust-lang#121192 (Give some intrinsics fallback bodies) - rust-lang#121197 (Ensure `./configure` works when `configure.py` path contains spaces) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 17, 2024
Rollup merge of rust-lang#121135 - Zalathar:no-whole-body-span, r=wesleywiser coverage: Discard spans that fill the entire function body While debugging some other coverage changes, I discovered a frustrating inconsistency that occurs in functions containing closures, if they end with an implicit `()` return instead of an explicit trailing-expression. This turns out to have been caused by the corresponding node in MIR having a span that covers the entire function body. When preparing coverage spans, any span that fills the whole body tends to cause more harm than good, so this PR detects and discards those spans. (This isn't the first time whole-body spans have caused problems; we also eliminated some of them in rust-lang#118525.)
This was referenced Feb 18, 2024
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.
While debugging some other coverage changes, I discovered a frustrating inconsistency that occurs in functions containing closures, if they end with an implicit
()return instead of an explicit trailing-expression.This turns out to have been caused by the corresponding node in MIR having a span that covers the entire function body. When preparing coverage spans, any span that fills the whole body tends to cause more harm than good, so this PR detects and discards those spans.
(This isn't the first time whole-body spans have caused problems; we also eliminated some of them in #118525.)