-
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
Known limitations of branch coverage instrumentation #124118
Comments
Based on my investigations so far:
|
There's also some discussion at #79649 (comment) about whether the right-hand-side of a lazy boolean expression ( My view is that “branch coverage” should not be in the business of instrumenting things that clearly aren't branches at the language level, at least not by default. There are valid use-cases for that behaviour, but if it exists then it should require some additional level of opt-in beyond just enabling branch coverage. (If people want to discuss this point further, I would suggest creating a separate issue for that discussion.) |
Is there a draft folk for I have tried a bit and found a possibly feasible way to insert block markers, see a naive draft. Because By this then |
I managed to get my match-arm idea working, so I'll try to tie up the loose ends and post it as a PR. |
#124154 shows my current approach to instrumenting |
I now have draft PRs for if-let, let-else, and match arms (without or-patterns). |
coverage: Prepare for improved branch coverage When trying to rebase my new branch coverage work (including rust-lang#124154) on top of the introduction of MC/DC coverage (rust-lang#123409), I found it a lot harder than anticipated. With the benefit of hindsight, the branch coverage code and MC/DC code have become more interdependent than I'm happy with. This PR therefore disentangles them a bit, so that it will be easier for both areas of code to evolve independently without interference. --- This PR also includes a few extra branch coverage tests that I had sitting around from my current branch coverage work. They mostly just demonstrate that certain language constructs listed in rust-lang#124118 currently don't have branch coverage support. `@rustbot` label +A-code-coverage
coverage: Prepare for improved branch coverage When trying to rebase my new branch coverage work (including rust-lang#124154) on top of the introduction of MC/DC coverage (rust-lang#123409), I found it a lot harder than anticipated. With the benefit of hindsight, the branch coverage code and MC/DC code have become more interdependent than I'm happy with. This PR therefore disentangles them a bit, so that it will be easier for both areas of code to evolve independently without interference. --- This PR also includes a few extra branch coverage tests that I had sitting around from my current branch coverage work. They mostly just demonstrate that certain language constructs listed in rust-lang#124118 currently don't have branch coverage support. ``@rustbot`` label +A-code-coverage
Rollup merge of rust-lang#124217 - Zalathar:pre-branch, r=oli-obk coverage: Prepare for improved branch coverage When trying to rebase my new branch coverage work (including rust-lang#124154) on top of the introduction of MC/DC coverage (rust-lang#123409), I found it a lot harder than anticipated. With the benefit of hindsight, the branch coverage code and MC/DC code have become more interdependent than I'm happy with. This PR therefore disentangles them a bit, so that it will be easier for both areas of code to evolve independently without interference. --- This PR also includes a few extra branch coverage tests that I had sitting around from my current branch coverage work. They mostly just demonstrate that certain language constructs listed in rust-lang#124118 currently don't have branch coverage support. ``@rustbot`` label +A-code-coverage
Noticed the match arms pay attention to occasion like comment at first line of Many redundant expressions like this may be introduced by match arms.
The However, given that |
This might not be "apparent". We also can view |
…er-errors coverage: Branch coverage support for let-else and if-let This PR adds branch coverage instrumentation for let-else and if-let, including let-chains. This lifts two of the limitations listed at rust-lang#124118.
…er-errors coverage: Branch coverage support for let-else and if-let This PR adds branch coverage instrumentation for let-else and if-let, including let-chains. This lifts two of the limitations listed at rust-lang#124118.
…-errors coverage: Branch coverage support for let-else and if-let This PR adds branch coverage instrumentation for let-else and if-let, including let-chains. This lifts two of the limitations listed at rust-lang#124118.
I've rewritten the issue description to give a more up-to-date summary of the status quo. |
Branch coverage is known to support these branching language constructs:
if
andwhile
if let
and let-chains||
and&&
as separate brancheswhile
desugars toif
before MIR building, so we support it as a consequence of supportingif
||
and&&
expressions||
and&&
are treated as separate brancheslet
-else
statementsif
expressions before MIR buildingif let
guardsBranch coverage is known to not yet support these branching language constructs:
match
expressions?
operator (which conditionally returns)match
expression, so once we support those, supporting?
should mostly be a matter of expansion-span bookkeeping.await
expressions (which implicitly “return” when the enclosing future is dropped)?
Relevant PR links:
(Rewritten on 2024-07-11; see edit history for the old text.)
The text was updated successfully, but these errors were encountered: