coverage: Clarify some parts of coverage counter creation#130380
Merged
bors merged 7 commits intorust-lang:masterfrom Sep 17, 2024
Merged
coverage: Clarify some parts of coverage counter creation#130380bors merged 7 commits intorust-lang:masterfrom
bors merged 7 commits intorust-lang:masterfrom
Conversation
Collaborator
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
Collaborator
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
- Look up the node's predecessors only once - Get rid of some overly verbose logging - Explain why some nodes need physical counters - Extract a helper method to create and set a physical node counter
By building the list of candidate edges up-front, and making the candidate-selection method fallible, we can remove a few pieces of awkward code.
This does a better job of expressing the special cases that occur when a node in the coverage graph has exactly one in-edge.
Given that we directly access the graph predecessors/successors in so many other places, and sometimes must do so to satisfy the borrow checker, there is little value in having this trivial helper method.
Swatinem
approved these changes
Sep 15, 2024
jieyouxu
approved these changes
Sep 16, 2024
Member
jieyouxu
left a comment
There was a problem hiding this comment.
Thanks, AFAICT the changes look reasonable and does simplify the implementation quite a bit. Please feel free to r=me unless you specifically want someone else to look at this.
Member
Author
|
Thanks. @bors r=jieyouxu |
Collaborator
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 17, 2024
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#130380 (coverage: Clarify some parts of coverage counter creation) - rust-lang#130427 (run_make_support: rectify symlink handling) - rust-lang#130447 (rustc_llvm: update for llvm/llvm-project@2ae968a0d9fb61606b020e898d88…) - rust-lang#130448 (fix: Remove duplicate `LazyLock` example.) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 17, 2024
Rollup merge of rust-lang#130380 - Zalathar:counters, r=jieyouxu coverage: Clarify some parts of coverage counter creation This is a series of semi-related changes that are trying to make the `counters` module easier to read, understand, and modify. For example, the existing code happens to avoid ever using the count for a `TerminatorKind::Yield` node as the count for its sole out-edge (since doing so would be incorrect), but doesn't do so explicitly, so seemingly-innocent changes can result in baffling test failures. This PR also takes the opportunity to simplify some debug-logging code that was making its surrounding code disproportionately hard to read. There should be no changes to the resulting coverage instrumentation/mappings, as demonstrated by the absence of changes to the coverage test suite.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Oct 22, 2024
coverage: Make counter creation handle node/edge counters more uniformly Similar to rust-lang#130380, this is another round of small improvements informed by my ongoing attempts to overhaul coverage counter creation. One of the big benefits is getting rid of the awkward special-case that would sometimes attach an edge counter to a node instead. That was needed by the code that chooses which out-edge should be given a counter expression, but we can avoid that by making the corresponding check a little smarter. I've also renamed several things to be simpler and more consistent, which should help with future changes.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 22, 2024
Rollup merge of rust-lang#131918 - Zalathar:counters, r=nnethercote coverage: Make counter creation handle node/edge counters more uniformly Similar to rust-lang#130380, this is another round of small improvements informed by my ongoing attempts to overhaul coverage counter creation. One of the big benefits is getting rid of the awkward special-case that would sometimes attach an edge counter to a node instead. That was needed by the code that chooses which out-edge should be given a counter expression, but we can avoid that by making the corresponding check a little smarter. I've also renamed several things to be simpler and more consistent, which should help with future changes.
This file contains hidden or 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
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.
This is a series of semi-related changes that are trying to make the
countersmodule easier to read, understand, and modify.For example, the existing code happens to avoid ever using the count for a
TerminatorKind::Yieldnode as the count for its sole out-edge (since doing so would be incorrect), but doesn't do so explicitly, so seemingly-innocent changes can result in baffling test failures.This PR also takes the opportunity to simplify some debug-logging code that was making its surrounding code disproportionately hard to read.
There should be no changes to the resulting coverage instrumentation/mappings, as demonstrated by the absence of changes to the coverage test suite.