[improvement] Differentiating uncovered because not tested or filtered

[Maze-fr]

Is your feature request related to a problem? Please describe.
I use a filter on JaCoCo (Java) to exclude some classes from the coverage report (generated classes, POJO, Spring properties classes, Spring configuration, etc.).
When I "watch" for the coverage, the filtered classes appear as "uncovered".

Describe the solution you'd like
I would like my filtered classes to appear as "filtered" or "excluded" instead of "uncovered", so I can differentiate on sight what I uncovered from what I deliberately don't want to cover.

Describe alternatives you've considered
When a class / file isn't in the coverage report, it should be labelled as "filtered" or "excluded" instead of "uncovered".

Additional context
When searching to improve code coverage for the quality gate in Sonar, it would be nice not wasting time on filtered classes.

[ryanluker]

@Maze-fr Interesting, thanks for the ticket!

ATM we only really support 3 coverage states (full, partial, none) as that was the direction the lcov file format provided.
We would have to look into jacoco's output to see if a filtered state is possible so we can filter that out in the coverage consumer.

vscode-coverage-gutters/src/files/coverageparser.ts

Lines 93 to 114 in b4c638f

	private xmlExtractJacoco(filename: string, xmlFile: string) {
	return new Promise<Map<string, Section>>((resolve) => {
	const checkError = (err: Error) => {
	if (err) {
	err.message = `filename: ${filename} ${err.message}`;
	this.handleError("jacoco-parse", err);
	return resolve(new Map<string, Section>());
	}
	};
	try {
	parseContentJacoco(xmlFile, async (err, data) => {
	checkError(err);
	const sections = await this.convertSectionsToMap(data);
	return resolve(sections);
	});
	// eslint-disable-next-line @typescript-eslint/no-explicit-any
	} catch (error: any) {
	checkError(error);
	}
	});
	}

At first glance, it doesn't appear like the package we use has that exposed atm.
https://github.com/7sean68/jacoco-parse/blob/master/source/index.js#L74-L97

---EDIT---
Another thought came to mind, we might be able to have a filtered / ignored list in the coverage gutters settings but that sounds annoying to keep up to date with your jacoco filtering list...

[Maze-fr]

I may have a different list of filtered resources in each project, because I use a property I declared in Maven, and use it in the configuration of the JaCoCo Maven plugin.
So, why I thought, is that you could read the filter property from the JaCoCo Maven plugin configuration.

[ryanluker]

I may have a different list of filtered resources in each project, because I use a property I declared in Maven, and use it in the configuration of the JaCoCo Maven plugin. So, why I thought, is that you could read the filter property from the JaCoCo Maven plugin configuration.

Hmm one option could involve parsing from the coverage file via the JaCoCo javascript module we use.
https://github.com/7sean68/jacoco-parse

If that provided the filtered files, we could then filter them out in the extension to avoid seeing those as "no coverage".

A second option might involve persisting the filtered files into the vscode extension via the settings.json and then the extension could also ignore coverage (or lack of coverage) if the file path matches.