Exclude functions from code coverage

[laksru]

Hello,
It is good that we can exclude files from code coverage using config files and regex patterns.
Is there any way that we can exclude functions in a file using filters and exclusion markers from config files.

For example, I am looking for a way to exclude functions from code coverage when we add the function names in the config file.
In coverage.py for python, we can add "pragma: no cover" and list of function names in the config file to ignore those functions. In a similar way, can we do it in gcovr?
Please suggest.

[Spacetown]

You can add GCOVR_EXCL_START and GCOVR_EXCL_STOP around the functions which shall be excluded. See also https://gcovr.com/en/stable/guide.html#exclusion-markers.

[laksru]

Hello,

Thank you for your response.
I tried adding the START and STOP exclusion markers in the code to exclude the functions. But we have a huge community code base with several functions and lines of code untouched. I am thinking if we can write a list of functions to include for each feature and add it to the config files instead of adding markers directly in the source code.

Like in coverage.py for python, where we can add the list of functions in the configuration files that excludes functions from code coverage.

"exclude_lines =
pragma: no cover
def repr
if self.debug:
if settings.DEBUG"
Reference : https://coverage.readthedocs.io/en/latest/excluding.html

Please share your ideas.

[Spacetown]

At the moment you can use --exclude-lines-by-pattern but you have to create one big regular expression to match all the lines. to exclude from coverage. I did a quick check and I think for nested branches you have to exclude all branches.

[laksru]

Thank you and sorry for the late response.

Do you think it is possible to have a feature like "Pragma: no cover" available in coverage.py that excludes functions from coverage.
As we have a huge code base, it is not feasible to have a big regex patterns.
Instead I feel it would be great to have a config file with a list of functions to be excluded.

Please suggest.

[latk]

The essential difference is that coverage.py works on the level of Python syntax blocks. When you ignore the line introducing a block (if, def, …), the entire block is ignored.

In contrast, gcovr works on the level of source code lines. Gcovr is completely language-agnostic, and does not attempt to parse source code (aside from some very minor heuristics). The underlying data source usually does include function coverage information (which we want to make use of, e.g. see #325, #362). At some point far into the future it might be possible to ignore any line contained by a particular function or block. However, there will be further problems that Python doesn't have, e.g. name mangling and template specialization.

I understand the desire for this feature, but there's no plausible path to actually implement it within a reasonable horizon (I'd estimate it at about 80 person-hours of work, assuming the necessary function coverage information can be extracted easily). But as explained, coverage exclusion markers can be added to achieve the desired effect. We just can't add the convenience feature to ignore a function in one go.

[latk]

There is a similar issue regarding lcov at linux-test-project/lcov#116. One suggested alternative to only get “interesting” coverage statistics was to use differential coverage tools. The discussion also pointed out difficulties with handling nested functions, which can even occur in C (with GCC extensions).

[kschwab]

Hi @latk,

I wanted to check back in on this request. I stumbled upon this thread when planning to raise a similar question.

However, the difference now is that lcov supports the above with --erase-function. It was added earlier this year, about two years after this discussion was closed.

Do you believe this work still falls in the camp of 80 person-hours of work, wontfix etc, or have conditions changed since then that would now make it easier to tackle? We would really like to use gcovr, but at present we need a "simple" way of excluding functions at report generation time.

[latk]

Hi @kschwab! Gcovr has started collecting per-function coverage statistics that might also facilitate exclusion processing. There would still be challenges (nested functions, template specialization, name mangling) but it might be good enough for C-style code.

Gcovr now has an architecture where exclusions are processed in multiple passes. It would be possible to implement another pass that essentially treats functions as start/stop exclusion markers.

I don't have the energy for active contributions to gcovr, so I won't do this myself. But I'll support anyone who does.

[kschwab]

Thank you @latk. If I get the time I will try and lend a hand if possible.

Would you like me to create a new issue for tracking this, or can we transition this current one back into opened state?

[latk]

I've reopened this issue.

A good starting point to work on this would be to look at the existing exclusion processing passes and at the FunctionCoverage data model. Note that lcov knows the end_line of a function because they process the gcov JSON output, we unfortunately still don't (#282, no technical blockers, it's just that no one got around to it). So instead, we would probably use the line number of the next function in the file as the end marker.