Add path context to filter options in config files

[kjerstadius]

Addresses #300. From the "main" commit message:

By using a dedicated type for filter options it's possible include the
path context for a filter. This enables (relative) filters in config
files to be treated as relative to the location of the config file,
rather than relative to the current working directory.

Handling and behavior of CLI arguments is the same as before. Do note that the check_non_empty() function ended up being unused, so I removed it (in a separate commit though, so easy to roll back).

[kjerstadius]

This option (and gcov_excludes as well) previously didn't use the check_non_empty() function. I wasn't sure if that was deliberate or not, but in the current iteration of the code that will be a slight behavioral change. I had to modify a test case to deal with this fact.

[latk]

I'll have to think a bit more about this.

An empty filter would be a regex that always matches, and can be used to deactivate a filter. This is most important for the --filter option to deactivate filtering (the default would filter to files under --root).

But I don't think this would be useful for --gcov-filter or --gcov-exclude: it doesn't make sense to exclude all files, and accepting all files already is the default. That only leaves use cases like “deactivating filters in a configuration file” which I'm not interested in supporting at the moment.

[kjerstadius]

Couldn't really figure out the necessity of this argument as it seems to have no effect or relation at all to the actual test.

[latk]

I now understand why --gcov-exclude was used here. The capture() test driver runs gcovr's main(). It actually searches for coverage data and creates a report. But this test is not about the reports, only about side effects. Setting --gcov-exclude to an empty filter ensures that no coverage data will be found, which should make the test more robust. The empty filter is the easiest way to write a filter that always matches, here: excludes all files.

[codecov]

Codecov Report

Merging #304 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #304      +/-   ##
==========================================
+ Coverage   94.89%   94.91%   +0.01%     
==========================================
  Files          15       15              
  Lines        1823     1830       +7     
  Branches      315      316       +1     
==========================================
+ Hits         1730     1737       +7     
  Misses         46       46              
  Partials       47       47

Impacted Files	Coverage Δ
gcovr/utils.py	93.58% <100%> (+0.34%)	⬆️
gcovr/__main__.py	93.05% <100%> (ø)	⬆️
gcovr/tests/test_args.py	100% <100%> (ø)	⬆️
gcovr/configuration.py	97.2% <100%> (-0.02%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c018e2b...cd6461e. Read the comment docs.

[kjerstadius]

Not sure if ArgumentTypeError is the most appropriate exception to use here, but I'd say it's the most straightforward to get behavior that's as similar as possible to before. I evaluated other alternatives but none really stuck. ValueError could be used, but using it will print a standardized error rather than a custom one. It will also print a traceback which the Argparse exception handling won't. If the behavior of the Argparse exception is to be preferred (mainly no traceback) a custom program exit function would need to be written. It would of course also be possible to leverage check_non_empty() to check that the value is set before passing it to the class constructor similar to how it was before, but then it would only apply to CLI args and not config file filters.