-
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: Rearrange the code for embedding per-function coverage metadata #134163
Conversation
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
This comment has been minimized.
This comment has been minimized.
e0ad6ad
to
ec7eb7e
Compare
@bors try |
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
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!
I think this PR doesn't change the functionality. Just making some comments for the code.
☀️ Try build successful - checks-actions |
Added some more comments in response to feedback (diff). |
This defers the call to `llvm_cov::write_function_mappings_to_buffer` until just before its enclosing global variable is created.
I had another look at that test, and changing it to use CHECK-DAG was easier than I expected, so I just fixed it. |
No further concerns from me, feel free to r=Sparrow and me if @SparrowLii has no further concerns. |
LGTM |
Thanks for the reviews. @bors r=SparrowLii,jieyouxu |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#132975 (De-duplicate and improve definition of core::ffi::c_char) - rust-lang#133598 (Change `GetManyMutError` to match T-libs-api decision) - rust-lang#134148 (add comments in check_expr_field) - rust-lang#134163 (coverage: Rearrange the code for embedding per-function coverage metadata) - rust-lang#134165 (wasm(32|64): update alignment string) - rust-lang#134170 (Subtree update of `rust-analyzer`) r? `@ghost` `@rustbot` modify labels: rollup
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
// If there are no covfun records for this CGU, don't generate a covmap record. | ||
// Emitting a covmap record without any covfun records causes `llvm-cov` to | ||
// fail when generating coverage reports, and if there are no covfun records | ||
// then the covmap record isn't useful anyway. | ||
// This should prevent a repeat of <https://github.com/rust-lang/rust/issues/133606>. | ||
if covfun_records.is_empty() { | ||
return; | ||
} |
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.
Sorry, it only occurred to me post-merge as I was looking at #134208. Did we ever have a regression test for this case (I imagine it can be hard to come with up with one)?
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.
It should be possible, but I would have to do some non-trivial detective work, because currently we don't have any examples smaller than “the coverage tests for my entire workspace, in CI”.
…-errors coverage: Tidy up creation of covmap and covfun records This is a small follow-up to rust-lang#134163 that mostly just inlines and renames some variables, and adds a few comments. It also slightly defers the creation of the LLVM value that holds the filename table, to just before the value is needed.
coverage: Tidy up creation of covmap and covfun records This is a small follow-up to rust-lang#134163 that mostly just inlines and renames some variables, and adds a few comments. It also slightly defers the creation of the LLVM value that holds the filename table, to just before the value is needed. --- try-job: x86_64-mingw-2
…-errors coverage: Tidy up creation of covmap and covfun records This is a small follow-up to rust-lang#134163 that mostly just inlines and renames some variables, and adds a few comments. It also slightly defers the creation of the LLVM value that holds the filename table, to just before the value is needed. --- try-job: x86_64-mingw-2
…-errors coverage: Tidy up creation of covmap and covfun records This is a small follow-up to rust-lang#134163 that mostly just inlines and renames some variables, and adds a few comments. It also slightly defers the creation of the LLVM value that holds the filename table, to just before the value is needed. --- try-job: x86_64-mingw-2
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. Thellvm-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 #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