Skip to content
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

Fix parsing of BRDA lines in LcovParser #11899

Closed
wants to merge 3 commits into from

Conversation

c-mita
Copy link
Member

@c-mita c-mita commented Aug 6, 2020

Fixes the interpretation of the "-" in a BRDA line (meaning the branch
was never executed, as opposed to executed but never taken) and fixes
the internal SourceFileCoverage abstraction to account for the fact that
multiple BRDA statements will occur for the same line.

Based on the PR #10708 but does
not include any changes for the Java code coverage generator.

Fixes #11051

Fixes the interpretation of the "-" in a BRDA line (meaning the branch
was never executed, as opposed to executed but never taken) and fixes
the internal SourceFileCoverage abstraction to account for the fact that
multiple BRDA statements will occur for the same line.

Based on the PR bazelbuild#10708 but does
not include any changes for Java code coverage generator.

Fixes bazelbuild#11051
@c-mita c-mita added coverage team-Rules-Server Issues for serverside rules included with Bazel labels Aug 6, 2020
@c-mita c-mita requested a review from oquenchil August 6, 2020 13:17
@c-mita c-mita requested a review from lberki as a code owner August 6, 2020 13:17
@c-mita
Copy link
Member Author

c-mita commented Aug 6, 2020

Issues with the BRDA parser have come up in several pull requests that also target individual lcov generators (e.g. #10708, #11489).

There is still some confusion with how BranchCoverage objects get mapped to "BA" or "BRDA" in the Lcov output; which can be worked on separately.

@@ -36,7 +36,7 @@
static final String LH_MARKER = "LH:";
static final String LF_MARKER = "LF:";
static final String END_OF_RECORD_MARKER = "end_of_record";
static final String TAKEN = "-";
static final String NOT_TAKEN = "-";
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is better as "NEVER_EXECUTED", since it means the branches in a block were never executed, not just taken.

There's a bit of inconsistency with the usages of the words "taken" and "executed" when compared to the docs here: http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php

  BRDA:<line number>,<block number>,<branch number>,<taken>`

       Block  number  and  branch  number are gcc internal IDs for the branch.
       Taken is either '-' if the basic block containing the branch was  never
       executed or a number indicating how often that branch was taken.

We seem to have reversed the words "taken" and "execution"...

Copy link
Contributor

@oquenchil oquenchil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For both of the changes described, would you mind providing an example of how the lines looked like before vs. how they should like (how they look now)?

Copy link
Contributor

@oquenchil oquenchil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bazel-io bazel-io closed this in 5a8c461 Aug 7, 2020
bazel-io pushed a commit that referenced this pull request Aug 14, 2020
#11899 (5a8c461) changed
SourceFileCoverage to properly account for multiple branches on a
single line. However, it erroneously assumed that, during merges, all
input coverage objects would represent the entire source file and
required the exact same number of branches to be recorded in each
input, in the same order.

It may be that two SourceFileCoverage objects represent different parts
of a source file, and so contain information for different line numbers.
We should not fail to merge the branch information in these objects.

This refines the branch merging logic to operate "line by line". We
still require consistency in the inputs if both merge inputs have branch
information for the same line.

Closes #11932.

PiperOrigin-RevId: 326625481
luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this pull request Sep 4, 2022
    bazelbuild/bazel#11899 (5a8c461) changed
    SourceFileCoverage to properly account for multiple branches on a
    single line. However, it erroneously assumed that, during merges, all
    input coverage objects would represent the entire source file and
    required the exact same number of branches to be recorded in each
    input, in the same order.

    It may be that two SourceFileCoverage objects represent different parts
    of a source file, and so contain information for different line numbers.
    We should not fail to merge the branch information in these objects.

    This refines the branch merging logic to operate "line by line". We
    still require consistency in the inputs if both merge inputs have branch
    information for the same line.

    Closes #11932.

    PiperOrigin-RevId: 326625481
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes coverage team-Rules-Server Issues for serverside rules included with Bazel
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants