Closing Curly braces ("}") following return statements not ignored

[bcaddy]

I found that lcov is reporting lines with just a } that follow a return statement when they should just be excluded. I don't see this issue in other peoples coverage reports and lcov does appear to be excluding the opening { properly. What am I doing wrong?

[henry2cox]

You are doing nothing wrong (AFAIK). The bogus lines seem to be coming from gcov. You probably also noticed that those lines appear and disappear somewhat arbitrarily: different compiler version, changed flags, new or changed code, etc. I implemented a ‘--filter …” feature to remove (most of) these, plus a few other artifacts. You can see some discussions in issues #101, #108, and #98, and a discussion of the fix in pull request #86. You might want a more aggressive ‘line’ filter than the one I implemented. My goal was to eliminate bogus “UIC” and “LBC” code from differential coverage reports (…because those categories trigger our Jenkins to fail the job). Hope this helps Henry

[bcaddy]

Thanks, is --filter merged into LCOV yet? It's not showing up as an option in my lcov install (v1.15) and I'm limited to officially released version on the systems I run on

[henry2cox]

Sorry – not merged. There are two things you could do: - Download the fixed version and install somewhere in your sandbox. (May not endear you to IT or security guys.) - Put some exclude directives around the braces where this is happening. (This will be very painful/never-ending, as you will find new bogus lines appearing when you change code or environment – and even sometimes when you don’t.) The last option is to wait for the pull request to be merged (but it has been a year – so I recommend not to hold your breath.) Sorry to be the bearer of bad news. Henry

[bcaddy]

Bummer, thanks for your help!

[FreddyFunk]

@bcaddy 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.

[bcaddy]

Thank you, I'll try it out.