[question] Why only one braces is not covered in my project?

[paulocoutinhox]

Hi,

In my project appear in report that only one braces is not covered:

https://app.codecov.io/gh/nativium/nativium/blob/main/modules/app-core/implementation/cpp/nativium/core/ApplicationCoreImpl.cpp

Why this happen?

Thanks.

[henry2cox]

gcov artifact.
Very likely, some exception handling code (or something else) got inserted at the end of your function - but your code actually returns earlier than that so the coverage counter was not incremented. (You can check the asm code to see what the compiler actually created.)

My workaround is to filter the coverage data - in this case, to remove spurious zero counts from the function closing brace.
There is a longer discussion of the issue and the various other filters, in the 'differential coverage' pull request.

Hope that helps.

[paulocoutinhox]

Hi,

Im searching for this "remove zero counts from the function closing braces", but im not finding how to solve this for all files.

I found:

• Same issue: Closing Curly braces ("}") following return statements not ignored #129
• Add LCOV_EXCL_LINE to each line that i want exclude: https://stackoverflow.com/questions/20866420/lcov-branches-at-the-end-of-a-function

How i can do it globally (from command line or something like this)?

Thanks.

[henry2cox]

From #86, you will find a few references to "--filter" - but it looks like the bug report for #129 already refers to it. (edited to remove screen shot that did not translate :-( ) The page refers to my branch of the lcov repo. At present: you will need to download that branch if you want to use the feature. It is in the process of being merged to master – but the merge is not yet complete/not available. You _do_ need to be able to install that new version (somewhere – possibly in your own account if you don’t have sufficient permission and/or your IT group does not agree). I hope this helps. Henry

[xaizek]

As I remember, codecov scripts upload coverage information to their servers for processing. So you want to consult their documentation for some kind of filtering and if that's not present suggest ignoring coverage information on lines like } to them. I doubt they are using lcov at all.

[paulocoutinhox]

Sure, but locally the problem is the same with lcov report generator:

So, the real solution is fix lcov.

[xaizek]

Fixing lcov won't fix codecov.

[paulocoutinhox]

But codecov use the lcov data. It shows exactly the same data from lcov.

[xaizek]

Both codecov and lcov use data from gcov. There is no need to use lcov for codecov, it will only make things harder.

[henry2cox]

* Both codecov and lcov use data from gcov. There is no need to use lcov for codecov, it will only make things harder. I’m unfamiliar with ‘codecov’. However, if it is using the data format that is also used by ‘lcov’ – then you can use the various features (such as filtering) mentioned earlier to munge the data and then feed to codecov. It is also possible to simply port the new features into codecov – but that seems kinda boring/repetitive. Henry

[henry2cox]

* So you want to consult their documentation for some kind of filtering and if that's not present suggest ignoring coverage information on lines like } to them. I doubt they are using lcov at all. I forgot to mention that you probably don’t want to blindly ignore close-brace lines with hit counts on them, as sometimes they are relevant and sometimes not. For example: if (cond) { } <- 0 hit count here means branch not taken/condition not executed Similarly, void foo() { // … body removed if (return_now) { return; } } <- zero hit count probably means previous branch always taken … so context matters – and can get complicated (so the filter I implemented gives up). It is also true that the above examples are probably better handled by branch coverage metrics – but branch coverage has it own issues with bogosity. To really do a good job of filtering – you need to be a compiler. And if it was easy, gcc/llvm would likely already do it 😊 Henry

[henry2cox]

The "--filter ..." features described above have been merged.
I'm fairly confident that it will remove the artifacts that you find confusing.

Could you test the current TOT to see if it meets your requirements or not.
If all is good: please close this request.
If something is missing: please clarify what is needed.
Thanks
Henry

[FreddyFunk]

@paulocoutinhox In case you still got this issue, try adding the compile options -fno-elide-constructors and -fno-default-inline in addition to -fprofile-arcs and -ftest-coverage as it may also help with coverage of "missing" constructors and inline functions. This fixed a similar issue for me when I was using GNU/GCC 11.3.

[henry2cox]

No comments/no followup for quite some long period.
I believe that the issue is addressed by the --filter brace option (to geninfo, lcov, or genhtml).
Please give it a try.

I'm closing this issue. If there is still a problem: please either reopen this one or file a new issue. Please provide detailed description of problem - ideally with a small testcase which exhibits the issue. Thanks
Henry