Add Branch and Function coverage to lcov output.

[tomconnell-wf]

It would be nice to have coverage data on branches and function/methods.

afaict the coverage.json just has a list of lines hit, but no data on branches and functions. Also, there is no code in LcovFormatter that generates branch and function lines.

Side note, I'm not totally sure of the coverage.json format, but it seems like there are a lot of extraneous zeros in the lines hit:

{
    "type": "CodeCoverage",
    "coverage": [{
        "source": "dart:core-patch/type_patch.dart",
        "script": {
            "type": "@Script",
            "fixedId": true,
            "id": "libraries/1/scripts/dart%3Acore-patch%2Ftype_patch.dart",
            "uri": "dart:core-patch/type_patch.dart",
            "_kind": "library"
        },
        "hits": []
    }, {
        "source": "dart:core/errors.dart",
        "script": {
            "type": "@Script",
            "fixedId": true,
            "id": "libraries/1/scripts/dart%3Acore%2Ferrors.dart",
            "uri": "dart:core/errors.dart",
            "_kind": "library"
        },
        "hits": [517, 0, 518, 0, 208, 0, 219, 0, 240, 0, 267, 2, 268, 0, 285, 0, 287, 0, 289, 0, 314, 2, 319, 2, 316, 0, 321, 0, 334, 1, 341, 0, 342, 0, 343, 0, 346, 0, 347, 0, 348, 0, 349, 0, 350, 0, 354, 0, 385, 0, 386, 0, 391, 0, 396, 0, 399, 0, 402, 0, 533, 0, 536, 0, 540, 0, 424, 0, 485, 0, 486, 0, 554, 0, 145, 0, 164, 0, 172, 0, 175, 0, 180, 0, 181, 0, 183, 0, 184, 0, 185, 0, 187, 0, 188, 0, 189, 0, 502, 0, 503, 0, 504, 0, 505, 0, 69, 0, 78, 0, 79, 0, 81, 0, 82, 0, 84, 0, 416, 0, 99, 0, 569, 0, 570, 0, 572, 0, 546, 0]
    }, {
        "source": "dart:core-patch/immutable_map.dart",
        "script": {
            "type": "@Script",
            "fixedId": true,
            "id": "libraries/1/scripts/dart%3Acore-patch%2Fimmutable_map.dart",
            "uri": "dart:core-patch/immutable_map.dart",
            "_kind": "library"
        },
        "hits": [137, 0, 140, 0, 141, 0, 142, 0, 143, 0, 146, 0, 147, 0, 151, 0, 90, 0, 93, 0, 96, 0, 101, 0, 104, 0, 107, 0, 115, 0, 118, 0, 119, 0, 120, 0, 121, 0, 124, 0, 125, 0, 129, 0, 10, 1, 17, 5, 18, 3, 19, 3, 26, 3, 29, 1, 32, 0, 36, 4, 37, 6, 42, 0, 46, 0, 50, 0, 51, 0, 59, 0, 60, 0, 68, 0, 72, 0, 76, 0, 80, 0, 84, 0]
    },
...

[srawlins]

Big +1

[JZ-at-TP]

+1 from 2019

[nirwannursabda]

any update for Function coverage?
we already in the end of 2019 :)

[acoutts]

Would love to see this implemented as well! Looks like still there is no function coverage.

[felangel]

+1 from 2020

[micaelcid]

+1 from 2021

[a-siva]

/cc @liamappelbe

[liamappelbe]

It sounds like there's two separate requests here, both involving coarsening the coverage data to make it easier to read. I looked into the feasibility of supporting this in the VM (not for the web).

1. Function level. This is easy enough, because the VM service API can already give us code ranges for every function. We can coarsen the coverage data using these ranges. I will start work on this soon.
2. Branch/block level. This is much harder. There's no way of getting code ranges for blocks ATM. We could potentially add a new RPC to the API, but this would be quite a lot of work.

How important is the branch/block level info? Would function level info be sufficient for your needs?

[cmc5788]

It sounds like there's two separate requests here, both involving coarsening the coverage data to make it easier to read. I looked into the feasibility of supporting this in the VM (not for the web).

1. Function level. This is easy enough, because the VM service API can already give us code ranges for every function. We can coarsen the coverage data using these ranges. I will start work on this soon.
2. Branch/block level. This is much harder. There's no way of getting code ranges for blocks ATM. We could potentially add a new RPC to the API, but this would be quite a lot of work.

How important is the branch/block level info? Would function level info be sufficient for your needs?

My personal feeling is that with line level on one end and function level on the other, it would cover a good span.

branch would certainly be nice to have in the long-run, but the effort to value ratio seems like it would favor getting function coverage sooner.

[IchordeDionysos]

I would prefer branch coverage as it gives you way more information/metadata on what is actually covered than line and especially function coverage can give you!

I am really not sure what useful metric function coverage would give you?!

With Branch coverage, you can make informed decisions on how much of your if/else, switch/case, ... statements are covered and make sure that nobody accidentally missed an else statement, as it would be reflected in your coverage report that this else was not covered!

[a-siva]

bumping priority as it appears to be an issue for customers