llvm-cov: Branches cannot be seen on macro definitions in source view

[chapuni]

If a macro definition has branches (&& || ?:), they cannot be seen in source view.
They can be seen in expanded subviews if expansion is enabled.

They causes hidden counts between the summary and the source view. (See also #119282)

This has been there since the introduction of branch coverage.
https://reviews.llvm.org/D84467
9f2967b#diff-44b7cba1a9d87f9ec9e067d93ea9d29ea4d9c669942d73f89233e39e28f9a5f0R680-R683
in CoverageMapping::getCoverageForFile(StringRef Filename):

    // Capture branch regions specific to the function (excluding expansions).
    for (const auto &CR : Function.CountedBranchRegions)
      if (FileIDs.test(CR.FileID) && (CR.FileID == CR.ExpandedFileID))
        FileCoverage.BranchRegions.push_back(CR);

I don't understand the intent. CountedBranchRegions doesn't have any Expansions. CR.ExpandedFileID will be always zero.
As the result, it is handled as if CR.FileID == 0. This prevents branches to be seen outside the function.
(Expansion subview can show them since it uses getCoverageForFunction())

I think it'd make sense to show branches on macro defs in the source view, to prune 2nd condition (CR.FileID == CR.ExpandedFileID).
What do you think, @evodius96 ?

[evodius96]

The intention was to exclude expanded branches from the main file view since they can be displayed in the expansion subview in their expanded context, which I thought might make more sense. Also, I didn't want to duplicate them in the view. The intention was more of a practical one on my part. However, you're correct, CR.ExpandedFileID is always zero, making the check effectively incorrect, but I likely overlooked fixing it because it yielded the desired visual result regardless.

If you remove the 2nd clause, the branches will show up in both places, which is probably OK. The region counts are also shown there too. Just as long as it's not counted twice in the summary metric.