False positive for closing C++ brace after function return

[KineticTheory]

Summary

lcov is reporting that the closing brace at the end of a function definition is untested -- even when the return on the previous line is covered. This doesn't occur for most function blocks in my project but I am seeing dozens of these reports. This seems like a bug.

Example:

Is this a known issue? I'm using master from Jan 24, 2024.

[henry2cox]

Known bug/issue.

If you look at the gcov output, you will notice the unexercised end line. In some senses, lcov is a very simple translator which is showing you the data generated by another tool. Basically: lcov is just reporting bad data it got from gcov :-(

However: there is a workaround. See the doc for the --filter option in the 'genhtml' and/or 'lcov' man page. In this case, you probably wanted: $ lcov --capture -o filtered.info --filter brace -d myBuildDir ....

All the component tools support filtering - but you probably want to do it at the 'capture' stage rather than at HTML report generation. The reason is that you really do want those artifacts eliminated - they are just wrong - and you might want clean data in the future, say for pre-release differential analysis. This is particularly true when some or all of the code is generated and so not easily available later on. In contrast: region filtering is probably best done late - as you may want to check your result with and without exclusions; experience suggests that bugs often hide there. (Differential reports with or without subsetting are an easy way to do this.)

You are likely to want to use --filter branch if you want to measure branch coverage in C++ code - otherwise, the reports are just too noisy to be useful.

GCC is not alone in generating bogus artifacts. You will find them in llvm data as well. Sadly, some of the LLVM artifacts are not so easily eliminated.

Hope this helps

Henry

[henry2cox]

Forgot to mention: in certain cases, the coverpoint on the closing brace represents the 'else' of a terminal conditional. In that case, that it is meaningful - and should NOT be removed/ignored.

[KineticTheory]

Thank you for providing a detailed explanation.

[henry2cox]

One more thing I forgot to mention:

• the various filters need to see the source text - e.g., to check that '\<this> coverpoint is a close brace'
• this will go badly wrong if the source version used for filtering is not the same as the built code that was used to generate the data. The same thing will happen if the version used to generate the HTML 'source view' is different than the capture version - e.g., the 'statement on line 10" isn't actually on line 10 any more.

This can be very confusing.

To help avoid the issue, lcov/genhtml/geninfo support a --version-script callback mechanism - to insert version data into the coverage DB and to check for version consistency for filtering, aggregation, report generation, etc.

[henry2cox]

One more obvious statement (sorry!):

If you are interested to check what the filters actually did, you can capture data with filtering and again without filtering - then generate a differential report, comparing those two. If unfiltered is passed as --baseline-fille and filter is passed as current, then the remove coverpoints will show up as EUB and ECB.