rust
rust copied to clipboard
rust-lang
coverage: Split out counter increment sites from BCB node/edge counters
This makes it possible for two nodes/edges in the coverage graph to share the same counter, without causing the instrumentor to inject unwanted duplicate counter-increment statements.
@rustbot label +A-code-coverage
For historical context, the original implementation of coverage didn't really distinguish between referring to a counter and incrementing that counter. The work done for https://github.com/rust-lang/compiler-team/issues/645 ended up creating a clean separation between those two concepts in most of the coverage code, but the one remaining holdout was the code that is updated by this PR.
This is a necessary step towards allowing the instrumentor to be a bit smarter about how it assigns counters to nodes/edges in the coverage graph.
For example, future PRs might allow it to observe that the coverage expression c1 + (c0 - c1) is equivalent to just c0, and avoid creating the intermediate expressions. Without this PR, doing so would have the unwanted side-effect of emitting extra counter-increments for c0, which would give wildly incorrect coverage counts.
The change lgtm. Is it possible to design a test that is changed by this PR? It seems like an important enough edge case to warrant ensuring the generated coverage statements don't change across future changes.
By itself, this PR still inserts exactly the same counters in exactly the same places.
It's now legal for multiple nodes or edges to share the same counter, but the code that actually sets up the counters was historically written under the assumption that sharing was not allowed (and isn't substantially changed by this PR), so currently that sharing never actually happens.
(I've been experimenting with some follow-up changes that do take advantage of this PR, but they are more involved and need some more polish, so I haven't included them here.)
If a future change somehow causes counters to be inappropriately duplicated, or inserted in the wrong places, that should typically show up as incorrect line coverage counts in the .coverage snapshot files.
