In the file above, there are 2 segments that are clear:
[start_line, start_col => end_line, end_col]
[2,1 => 6, 2] and [4, 4 => 5, 5]
covering both the function and the if's body scopes.
This leaves us with the following list:
My understanding is, that every segment, that has IsRegionEntry set
should be a region opening, whereas if it's unset, it is closing the
last open most-inner region, so:
[3,8,1,1,1] means we "open" new region at position 3,8 and
[3,22,0,1,1] means we "open" a nested region at position 3,22.
The `IsRegionEntry` field is set when a segment corresponds to a source region with a fresh profiling counter. Otherwise it is not set. I don't think it will be helpful to think of segments as "closing" a region.
- We need a fresh profiling counter for "argc > 1", because its execution count cannot be determined any other way. So `IsRegionEntry` is set.
- The same for "argc < 10".
- The final segment on line 3 is different, and does not have `IsRegionEntry` set. That's because its execution count can be derived from existing counters.
The `IsRegionEntry` field is just used as a hint by llvm-cov to compute better line execution counts, and to determine when it is appropriate to create tooltips for regions within a line.
[3,33,1,1,0] would mean that at position 3,33 we are closing the
last open region, that is, the one open at 3,22.
but in this case we are missing the "closing mark" for region open at
If you choose to think of segments as 'closing' a region, consider that one may 'close' multiple regions.
If the above is incorrect, please let me know how could I parse the
segments from json file to have source code properly annotated with
The design goal for the segment information was to "do all the work" of figuring out which execution counts correspond to which snippets of text. If you look at the SourceCoverageViewHTML::renderLine function in llvm-cov, you can see an example of how this is done (hopefully the comments help).
What kind of source annotations are you interested in? If it's similar to something llvm-cov does, I can provide more details about how it works.
So far I am using a recursive function keeping track of the last
"unclosed" segment at the current level and recursing whenever there
is another one opening with the last one not closed.
It sounds like you may be running into issues with the lack of explicit "end-of-segment" information in the CoverageSegment data structure. That information is implicit in the order in which the segments are presented.
I suggest breaking each line into snippets of text, where each snippet corresponds to exactly one CoverageSegment. This is what SourceCoverageViewHTML::renderLine does.
I hope this is clear enough
Thanks for your interest! Please keep us updated on how your tool develops.