[cfe-dev] probable bug in clang source based coverage

[Michał Pszona via cfe-dev]

Vedant,
Thanks for your reply.

I would submit a bug, if I would be sure this actually is a bug :)

So let me clear my understanding of the segments.
(This is based solely on this use of Segment type here
https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/tools/llvm-cov/CoverageExporterJson.cpp;298288$285
and llvm mapping format doc:
http://llvm.org/docs/CoverageMappingFormat.html
If you could point me to a better/more precise documentation, it would
be much appreciated)

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:
   [3,8,1,1,1],
   [3,22,0,1,1],
   [3,33,1,1,0]

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.
Now
   [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
position 3,8.

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
regions.
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.


I hope this is clear enough :)
regards,
Michał Pszona


On Mon, Mar 20, 2017 at 7:11 PM, Vedant Kumar <vsk at apple.com> wrote:
> The '&&' in your example belongs to the source region corresponding to the if condition. It is always 'reached' before '(argc > 1)' is reached, so the segment contains 'argc > 1) && ('. A new segment is pushed for 'argc < 10', because it isn't always reached when the '&&' is reached.
>
> This is why the current implementation does not emit a new segment just for the ' && ' snippet: it would be redundant.
>
> Also, there are no 'closing' segments, only new ones. Maybe this is just a terminology mix up.
>
> Let me know if the segments should be made more precise in any other way. If you have access to bugs.llvm.org, I'd appreciate any bug reports there (please add llvm-cov to the title).
>
> best,
> vedant
>
>> On Mar 20, 2017, at 5:37 AM, Michał Pszona via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>
>> All,
>>
>> I am parsing llvm-cov exports (json files) and I was surprised by some
>> of the outputs.
>> I was able to narrow it to the below example:
>>
>> the source file:
>>
>> int main (int argc, char* argv[])
>> {
>>   if ((argc > 1) && (argc < 10))
>>   {
>>   }
>> }
>>
>> the output:
>> https://gist.github.com/meahow/84f39ed625d138b42ee1b9cde7613b6a
>>
>> The confusing part is in segments section:
>>
>> "segments": [
>>   [2,1,1,1,1],
>>   [3,8,1,1,1],
>>   [3,22,0,1,1],
>>   [3,33,1,1,0],
>>   [4,4,0,1,1],
>>   [5,5,1,1,0],
>>   [6,2,0,0,0]
>> ],
>>
>>
>> It looks like there is unclosed region produced.
>> There are two opening marks in line 3 (cols 8 and 22) and one closing.
>> I believe that there should be another closing one in col 17.
>>
>> It looks like this behavior is easily reproducible with multi
>> statement conditions in if expression like this:
>>
>> if ( (a > 1) && (a < 5))
>> {}
>>
>> Can someone confirm that this is a bug or if I'm not getting it right ?
>>
>>
>> regards,
>> Michał Pszona
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>