-
Notifications
You must be signed in to change notification settings - Fork 13k
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: Store coverage source regions as Span
until codegen
#133418
Conversation
A used function with no mappings has historically indicated a bug, but that will no longer be the case after moving some fallible span-processing steps into codegen.
This will avoid confusion with actual `Span` spans.
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
Question: is there any kind of rough baseline performance / profile artifact size measurements we can compare this against? I understand if that is uhh non-trivial, but it might be interesting to see if there's any kind of method to track coverage artifact perf/size changes (not for this PR, ofc., just a general remark). I agree this is much nicer maintenance/impl-wise, so merits based on that alone is sufficient for me. |
For coverage instrumentation, we currently have very little of that sort of thing. None of the perf benchmarks enable (Sometimes that's convenient, because it means I don't have to spend time defending coverage-specific regressions caused by necessary refactoring work. But eventually it would be nice to have benchmarks rather than just vibes.) The main thing we do have is the But those metrics are unaffected by this PR, which (presumably) just gives a modest decrease in the amount of memory used to store coverage metadata in MIR. |
All that said, for this particular PR any improvement is just gravy, not an intentional goal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks like a nice robustness improvement to me.
if try_next && src.as_bytes()[end] == b'{' { | ||
Some(span.with_hi(hi + BytePos(1))) | ||
} else if try_prev && src.as_bytes()[start - 1] == b'}' { | ||
Some(span.with_lo(lo - BytePos(1))) | ||
} else { | ||
None | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remark: :ferrisAware:
but this is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm very much aware of why BytePos(1)
is bad news in general; in the past I have fixed BytePos(1)
bugs in the previous incarnation of this code.
In this very specific set of circumstances, we have confirmed in advance that the code point we're skipping over is a single byte (ASCII {
or }
), so adjusting by 1 to skip that character really is OK.
@bors r+ rollup=never (non-trivial coverage handling modifications) |
In this case I don't think there's benefit in avoiding rollup:
@bors rollup=maybe |
coverage: Store coverage source regions as `Span` until codegen Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass. This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as `Span` instead. In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because `Span` is smaller than 4x u32. --- There should be no changes to coverage output.
Rollup of 6 pull requests Successful merges: - rust-lang#116161 (Stabilize `extended_varargs_abi_support`) - rust-lang#132410 (Some more refactorings towards removing driver queries) - rust-lang#133418 (coverage: Store coverage source regions as `Span` until codegen) - rust-lang#133498 (Add missing code examples on `LocalKey`) - rust-lang#133518 (Structurally resolve before checking `!` in HIR typeck) - rust-lang#133521 (Structurally resolve before matching on type of projection) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#132410 (Some more refactorings towards removing driver queries) - rust-lang#133418 (coverage: Store coverage source regions as `Span` until codegen) - rust-lang#133498 (Add missing code examples on `LocalKey`) - rust-lang#133518 (Structurally resolve before checking `!` in HIR typeck) - rust-lang#133521 (Structurally resolve before matching on type of projection) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#133418 - Zalathar:spans, r=jieyouxu coverage: Store coverage source regions as `Span` until codegen Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass. This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as `Span` instead. In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because `Span` is smaller than 4x u32. --- There should be no changes to coverage output.
This reverts commit adf9b5f, reversing changes made to af1ca15. Reverting due to <rust-lang#133606>.
Revert rust-lang#133418 (Store coverage source regions as `Span`) due to regression rust-lang#133606 This reverts commit adf9b5f, reversing changes made to af1ca15. Reverting rust-lang#133418 due to regressions reported at rust-lang#133606. r? jieyouxu
Rollup of 7 pull requests Successful merges: - rust-lang#131323 (Support `clobber_abi` in AVR inline assembly) - rust-lang#133092 (Always set the deployment target when building std) - rust-lang#133134 (Don't use a SyntheticProvider for literally every type) - rust-lang#133538 (Better diagnostic for fn items in variadic functions) - rust-lang#133590 (Rename `-Zparse-only`) - rust-lang#133592 (Misc: better instructions for envrc, ignore `/build` instead of `build/`) - rust-lang#133608 (Revert rust-lang#133418 (Store coverage source regions as `Span`) due to regression rust-lang#133606) r? `@ghost` `@rustbot` modify labels: rollup
Revert rust-lang#133418 (Store coverage source regions as `Span`) due to regression rust-lang#133606 This reverts commit adf9b5f, reversing changes made to af1ca15. Reverting rust-lang#133418 due to regressions reported at rust-lang#133606. r? jieyouxu
coverage: Rearrange the code for embedding per-function coverage metadata This is a series of refactorings to the code that prepares and embeds per-function coverage metadata records (“covfun records”) in the `__llvm_covfun` linker section of the final binary. The `llvm-cov` tool reads this metadata from the binary when preparing a coverage report. Beyond general cleanup, a big motivation behind these changes is to pave the way for re-landing an updated version of rust-lang#133418. --- There should be no change in compiler output, as demonstrated by the absence of (meaningful) changes to coverage tests. --- try-job: x86_64-gnu try-job: x86_64-msvc try-job: aarch64-apple
…ouxu coverage: Rearrange the code for embedding per-function coverage metadata This is a series of refactorings to the code that prepares and embeds per-function coverage metadata records (“covfun records”) in the `__llvm_covfun` linker section of the final binary. The `llvm-cov` tool reads this metadata from the binary when preparing a coverage report. Beyond general cleanup, a big motivation behind these changes is to pave the way for re-landing an updated version of rust-lang#133418. --- There should be no change in compiler output, as demonstrated by the absence of (meaningful) changes to coverage tests. The first patch is just moving code around, so I suggest looking at the other patches to see the actual changes. --- try-job: x86_64-gnu try-job: x86_64-msvc try-job: aarch64-apple
Rollup merge of rust-lang#134163 - Zalathar:covfun, r=SparrowLii,jieyouxu coverage: Rearrange the code for embedding per-function coverage metadata This is a series of refactorings to the code that prepares and embeds per-function coverage metadata records (“covfun records”) in the `__llvm_covfun` linker section of the final binary. The `llvm-cov` tool reads this metadata from the binary when preparing a coverage report. Beyond general cleanup, a big motivation behind these changes is to pave the way for re-landing an updated version of rust-lang#133418. --- There should be no change in compiler output, as demonstrated by the absence of (meaningful) changes to coverage tests. The first patch is just moving code around, so I suggest looking at the other patches to see the actual changes. --- try-job: x86_64-gnu try-job: x86_64-msvc try-job: aarch64-apple
coverage: Store coverage source regions as `Span` until codegen (take 2) This is an attempt to re-land rust-lang#133418: > Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass. > This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead. > In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32. That PR was reverted by rust-lang#133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (rust-lang#133606). --- The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. rust-lang#134163). I believe that the changes in rust-lang#134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again. r? jieyouxu (reviewer of the original PR)
Rollup merge of rust-lang#134497 - Zalathar:spans, r=jieyouxu coverage: Store coverage source regions as `Span` until codegen (take 2) This is an attempt to re-land rust-lang#133418: > Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass. > This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead. > In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32. That PR was reverted by rust-lang#133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (rust-lang#133606). --- The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. rust-lang#134163). I believe that the changes in rust-lang#134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again. r? jieyouxu (reviewer of the original PR)
Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as
Span
instead.In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because
Span
is smaller than 4x u32.There should be no changes to coverage output.