Inconsistent branch counting in F# match expression

[SteveGilham]

My Framework

• .NET 2
• .NET 3.5
• .NET 4
• .NET 4.5
• .NET 4.6
• .NET 4.6.1
• .NET 4.6.2
• .NET Core 1.0.0
• .NET Core 2.0.5

My Environment

• Windows 7 or below (not truly supported due to EOL)
• Windows 8
• Windows 8.1
• Windows 10
• Windows 10 IoT Core
• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2016

I have already...

• repeated the problem using the latest stable release of OpenCover.
• reviewed the usage guide and usage document.
• have looked at the opencover output xml file in an attempt to resolve the issue.
• reviewed the current issues to check that the issue isn't already known.

My issue is related to (check only those which apply):

• no coverage being recorded
• inconsistent coverage being recorded
• 32 or 64 bit support
• feature request

Expected Behavior

The bec= value for a sequence point should equal the number of paths counted within it

Actual Behavior

Only part of a complicated branching gets counted in the bec= value

Steps to reproduce the problem:

The code I have looks like

type internal Close =
    | ...
    | Pause
    | Resume

type internal Message =
    | AsyncItem of ...
    | Item of ...
    | Finish of Close * ...

...
            match msg with // line 198
            | AsyncItem _ -> ...
            | Item _ -> ...
            | Finish (Pause, _) -> ...
            | Finish (Resume, _) -> ...
            | Finish _ -> ...

which decompiles to

			if (!(message is Message.Item))
			{
				if (!(message is Message.Finish))
				{
                                     ...
                                     return;
				}
				Message.Finish finish = (Message.Finish)msg;
				switch (finish.item1.Tag)
				{
				default:
                                     ...
                                     return;
				case 2: // Pause
                                     ...
                                     return;
				case 3: // Resume
                                     ...
                                     return;
				}
			}
                        ...
                        return;

The OpenCover XML for the match sequence point is

<SequencePoint vc="7" uspid="353" ordinal="4" offset="41" sl="198" sc="13" el="198" ec="27" bec="3" bev="3" fileid="324" />

with the next sequence point being at offset=190; but the branch points listed for the match offset are

<BranchPoint vc="0" uspid="379" ordinal="6" offset="112" sl="198" path="0" offsetchain="133" offsetend="414" fileid="324" />
<BranchPoint vc="2" uspid="380" ordinal="7" offset="112" sl="198" path="1" offsetchain="133" offsetend="414" fileid="324" />
<BranchPoint vc="3" uspid="381" ordinal="8" offset="112" sl="198" path="2" offsetchain="133" offsetend="414" fileid="324" />
<BranchPoint vc="1" uspid="382" ordinal="9" offset="112" sl="198" path="3" offsetchain="138" offsetend="320" fileid="324" />
<BranchPoint vc="1" uspid="383" ordinal="10" offset="112" sl="198" path="4" offsetchain="143" offsetend="367" fileid="324" />

which counts 5 paths (the first, uncovered one, being an instance of #786), the next 2 being the two values of the Close type that are treated as the default: case, then the two values treated individually.

What's interesting here is that we have 2 if statements and a 3(+2)-way match inside the sequence point, so one might expect more paths, ultimately corresponding to the five we see plus the two duplicated cases, to be reported here.

[sawilde]

The information comes from the PDB files if they are incorrect then it is garbage-in - garbage-out