[cfe-dev] Remove code coverage counter for "empty" lines

[Reid Kleckner via cfe-dev]

I have no understanding of any of the file formats involved, but it seems
like it would be the kind of thing we'd record in the information about the
source location, and then the tool that generates text or HTML can display
it how it likes at the end. That's why I support putting the info in the
LLVM IR format, since we'll need to track the bit through instrumentation.

If the file format is too hard to extend, then I wouldn't mind adding an
extra option for people who want to tweak our instrumentation.

On Wed, Sep 26, 2018 at 3:10 PM Vedant Kumar <vsk at apple.com> wrote:

> Hi,
>
> On Sep 25, 2018, at 12:46 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
> (+ a few folks who've been involved in the reviews, etc)
>
> On Mon, Sep 24, 2018 at 12:34 PM Calixte Denizet via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> When making code coverage, there are some counters on closing braces.
>> In some case it's due to "return void" with a debugloc corresponding to
>> '}' (see line 4) or due to cleanup stuff put at the end of a scope (see
>> line 20, aaa's dtor is called).
>> Especially with c++, some "implicit" code (i.e. not written explicitly by
>> the user) could be added at the beginning of a scope and at the end.
>> Here are two example of outputs produced by clang and gcc.
>>
>> With clang 7:
>> -:    1:struct A {
>> -:    2:
>> 1:    3:    A() {}
>> -:    4:
>> -:    5:    ~A() {
>> 1:    6:    }
>> -:    7:};
>> -:    8:
>> -:    9:void foo(int K) {
>> 1:   10:}
>> -:   11:
>> -:   12:int main() {
>> 1:   13:    A aaa;
>> 1:   14:    int x = 1;
>> 1:   15:    foo(x);
>> 1:   16:    x = x + 2;
>> -:   17:
>> 1:   18:    return x;
>> 1:   19:}
>>
>> With gcc 8:
>> -:    1:struct A {
>> -:    2:
>> 1:    3:    A() {}
>> -:    4:
>> 1:    5:    ~A() {
>> 1:    6:    }
>> -:    7:};
>> -:    8:
>> 1:    9:void foo(int K) {
>> 1:   10:}
>> -:   11:
>> 1:   12:int main() {
>> 1:   13:    A aaa;
>> 1:   14:    int x = 1;
>> 1:   15:    foo(x);
>> 1:   16:    x = x + 2;
>> -:   17:
>> 1:   18:    return x;
>> -:   19:}
>>
>> So I'd like to have coverage for lines which contain only "explicit" code
>> to have a clear information to give to different kinds of people (I spent
>> myself some time to understand why I had coverage on line like "} //
>> namespace foo”).
>>
>
> Makes sense, although I’ll note that there are cases where hiding coverage
> stats on closing braces might be doing a disservice, like:
>
> void foo() {
>   if (…)
>     return;
>   if (…)
>     return;
> } //< The coverage here might be interesting if you care about how often
> you don’t return early.
>
> You can figure it out by subtracting the coverage counts on return
> statements from the function entry count, but that’s work the coverage tool
> could do for you.
>
> So we could add an option in clang (no idea of the name right now) to
>> allow user to have coverage for explicit code.
>>
>
> I’d rather not have a flag to control this behavior. I imagine that most
> users of a coverage tool will never change its default behavior. From a
> maintenance perspective, it’s easier to test one coverage mode than two.
>
> You’re making a compelling argument that hiding coverage stats on implicit
> code is the right thing to do (if for no other reason than “it’s what gcc
> does”). If most others agree with you, I’d rather have such a change made
> unconditionally even though it’s not my personal preference.
>
> Just my 2 cents — happy to defer to others maintaining/using gcov.
>
> thanks,
> vedant
>
>
> And so have this output:
>> -:    1:struct A {
>> -:    2:
>> 1:    3:    A() {}
>> -:    4:
>> 1:    5:    ~A() {
>> -:    6:    }
>> -:    7:};
>> -:    8:
>> 1:    9:void foo(int K) {
>> -:   10:}
>> -:   11:
>> 1:   12:int main() {
>> 1:   13:    A aaa;
>> 1:   14:    int x = 1;
>> 1:   15:    foo(x);
>> 1:   16:    x = x + 2;
>> -:   17:
>> 1:   18:    return x;
>> -:   19:}
>>
>> Calixte
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181001/1520894e/attachment.html>