Add support for .lcovignore file to exclude files from coverage reports

[fedeegmz]

This PR introduces support for a .lcovignore file, allowing users to define patterns for files or directories that should be excluded from coverage reports. Lines starting with # are treated as comments and ignored. If a .lcovignore file is not present in the current directory, lcov behaves as usual.

Example .lcovignore:

lib/**/*.g.dart
# lib/**/*.freezed.dart
lib/assets/**
lib/data/api/services/apiServices.dart
lib/presentation/widgets/**

Signed-off-by: Federico Gomez gomez00federico@gmail.com

[henry2cox]

How is this different than adding a exclude = regexp line to the existing .lcovrc file (apart from being more limited in that it supports only exclusions), or adding a --config-file=$HOME/.lcovignore to your command line?

Three differences I see are that the patterns in the ignore file won't trigger an unused warning if they apply to nothing, the user won't see a count of the number of times each particular pattern was applied, and will see a perl error if there is a syntax error in the pattern.
I think you will see a few such errors when you parse your example .lcovignore example, above. (You appear to expect a form that is not quite a glob pattern and isn't a perl regexp.)

The feature seems limited in that it requires the ignore file to be in the run directory ($PWD) - which is probably not what you want in a larger project that contains multiple (reused) libraries.

There are no tests for this feature.

[fedeegmz]

Thanks for the detailed comments.

You're right - I hadn't considered the alternative of using the exclude = regexp option in .lcovrc. The idea is basically the same, although I personally prefer to keep the configuration cleaner by separating the ignore patterns into their own dedicated file, similar to .gitignore or .dockerignore.

As for the limitation of requiring the file to be in the current working directory - that's a fair point. A potential improvement could be to allow passing a custom path to the .lcovignore file via a CLI argument. This would give users more flexibility and avoid forcing them to place the file in $PWD. If this feature is deemed valuable, I would be happy to work to add it.

I see your point about the current limitations (e.g., lack of match counting, unused pattern warnings, and Perl syntax validation). Those are definitely areas that could be improved or clarified depending on how useful the feature is perceived to be.

Do you think having a separate ignore file like this could be a useful addition to lcov? If the feature seems too redundant or niche, I'm also happy to drop it - just wanted to explore if this could be useful to others as well.

Also, if you have any suggestions on how this could better align with lcov's current design or configuration philosophy, I'd love to hear them.

Thanks again!

[henry2cox]

You can pass multiple RC options file to the various lcov tools via the --config-file option - so you could separate your exclusions from other options if you wanted to.

• That might not be quite what you actually want, though - because you would have to pass at least 2 config files because the current implementation doesn't support loading a config file from another config file (i.e., because there is no config_file = ... lcovrc option today, and because the default lcovrc file is not loaded when the --config-file option is specified).
• If that was enhanced, then your master .lcovrc file could contain a line like
  config_file = $ENV{PWD}/.lcovignore
• an issue may be that you would get a usage error if the included file is not found (though you could --ignore the error)

With respect to counting and unused warnings: that might actually be feature - not an issue.
One might specify a generic list of things that one didn't want to include such that the list may or may not be applicable depending on project, toolchain, build mode, or whatever.

With respect to your more general question: yes. This seems rather niche.
OTOH: there are quite a few other rather niche features written into the tool today - primarily to support our various use cases.
Kind of not consistent for me to complain about other features.

All that said: I think that the most useful way to support this feature would be to add support for more general file inclusions. That could be useful for other purposes as well (e.g., project, team, and personal settings - which we do in a somewhat less convenient way today).

[henry2cox]

FWIW: I realized that it was quite simple, so I went ahead to implement a config_file = ... feature, as described above.
I will create a new PR for it shortly.

[henry2cox]

#407 is merged. I think that this one is now obsolete and can be closed.
What do you think?

[fedeegmz]

Yes, of course. Thank you for your work!