(DRAFT) Combined draft branch for coverage work#115428
(DRAFT) Combined draft branch for coverage work#115428Zalathar wants to merge 13 commits intorust-lang:masterfrom
Conversation
|
@rustbot label +A-code-coverage +S-experimental |
|
@rustbot author |
d86423d to
40bd399
Compare
|
Quick summary of some of the changes I have queued up:
|
|
☔ The latest upstream changes (presumably #114843) made this pull request unmergeable. Please resolve the merge conflicts. |
1b1d270 to
efae00c
Compare
|
@rustbot label -A-testsuite -T-bootstrap |
56a3e06 to
27dbb3c
Compare
|
☔ The latest upstream changes (presumably #115671) made this pull request unmergeable. Please resolve the merge conflicts. |
f4a5170 to
741330a
Compare
|
☔ The latest upstream changes (presumably #116154) made this pull request unmergeable. Please resolve the merge conflicts. |
172b77e to
a822b5b
Compare
|
Some of the changes I have queued up, that depend on #116046:
|
|
☔ The latest upstream changes (presumably #116409) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #115214) made this pull request unmergeable. Please resolve the merge conflicts. |
This query has a name that sounds general-purpose, but in fact it has coverage-specific semantics, and (fortunately) is only used by coverage code. Because it is only ever called once, it doesn't need to be a query, and we can change it to a regular function instead.
This test is mainly for detecting problems triggered by MIR optimizations, but the run-coverage tests don't enable optimization by default. (The coverage-map tests do enable optimization by default, but I'm updating the test anyway so that the two `unreachable.rs` files don't drift out of sync.)
…ters If a function has been instrumented for coverage, but MIR optimizations subsequently remove all of its counter-increment statements, then we won't emit LLVM counter-increment intrinsics. LLVM will think the function is not instrumented, and it will disappear from coverage mappings and coverage reports. This new MIR pass detects when that has happened, and re-inserts a dummy counter-increment statement so that LLVM knows to treat the function as instrumented.
…pings Most coverage metadata is encoded into two sections in the final executable. The `__llvm_covmap` section mostly just contains a list of filenames, while the `__llvm_covfun` section contains encoded coverage maps for each instrumented function. The catch is that each per-function record also needs to contain a hash of the filenames list that it refers to. Historically this was handled by assembling most of the per-function data into a temporary list, then assembling the filenames buffer, then using the filenames hash to emit the per-function data, and then finally emitting the filenames table itself. However, now that we build the filenames table up-front (via a separate traversal of the per-function data), we can hash and emit that part first, and then emit each of the per-function records immediately after building. This removes the awkwardness of having to temporarily store nearly-complete per-function records.
The code for creating these records was spread across multiple functions and multiple files, so this change moves as much of it as possible into one place.
|
☔ The latest upstream changes (presumably #116922) made this pull request unmergeable. Please resolve the merge conflicts. |
While waiting for #114843, juggling my patch queue is getting to be quite unwieldy, so I'm going to try putting all of my pending PRs (including some not filed yet) and some of my in-progress work in one linear branch.
r? @ghost