Allow for excluding files from the problem tab

[FieteO]

I have a java project that has a rather large proportion of files that are generated by openapi-generator. The generated code contains a lot of problems that I will not resolve (i.e The import XY is never used). This is cluttering the problems view.

I know that this view can be filtered and that there is the files.exclude option. I also found feature requests (#22289, #43135) for vscode to include a files.problemExclude option.

However this comment made me wonder if this could/should be rather implemented by this extension to ignore particular folders in the problem analysis.

[snjeza]

@FieteO you can try to add the following property

org.eclipse.jdt.core.compiler.problem.unusedImport=ignore

to <your_projects>/.settings/org.eclipse.jdt.core.prefs

See Settings Global Preferences

[FieteO]

Thanks for the suggestion @snjeza this does help, but is applied to the whole project. It kind of misses the point of ignoring problems for some subfolders though...

[rgrunber]

Could using @SuppressWarnings("all") on the type declaration work in your case ?

Supporting something like this properly might be possible, though maybe not as high priority given there's some ways of achieving roughly the same thing. I see that on the Eclipse side, the problem view filter settings are stored in the workspace in a file like org.eclipse.ui.ide.prefs. However, I assume much of the filtering is tied to the UI, so aside from some useful helper method, we'd probably end up writing this ourselves.

[FieteO]

@rgrunber I am not sure I fully understand what you are suggesting. Are you saying I should add @SuppressWarnings("all") to every generated java class? That would unfortunately be not possible as those classes are regenerated on each build

[rgrunber]

I mean adding the @SuppressWarnings to the source files, similar to https://github.com/eclipse/lemminx/blob/master/org.eclipse.lemminx/src/main/java/org/eclipse/lemminx/client/ExtendedCodeLensCapabilities.java#L26 . Or even @SupressWarnings("unused") to be more specific.

If applying them to the whole project is too much, then this should be a bit more granular as I don't think there is a way to suppress warnings on just those source files under a certain package.

[FieteO]

Apologies if I am missing your point and at the risk of repeating myself: In our setup the source files (i.e the restcontrollers) are completely transient, they are not versioned and rebuild with each gradle build. So in my eyes it is not possible to annotate them (maybe except for an openapi generator option I am not aware of), do you get what I mean?

[FieteO]

I just took a look on the openapi-generator issue tracker and found this related feature request to add @SuppressWarnings to the generated code. Maybe that would tackle the problem more at it's root.

[rgrunber]

You're right. I missed the "generated code" part in your first comment. Ok, so that workaround won't help in this case. It shouldn't be too difficult to implement some sort of diagnostic filtering. Just a question of whether such a capability should be done at the client (VS Code) level given how such a feature would likely be useful across many languages.

[rubensa]

I tried setting:

"settings": {
  "java.import.generatesMetadataFilesAtProjectRoot": true,

Then opening the generated .classpath and adding the ignore_optional_problems attribute like:

	<classpathentry kind="src" output="target/classes" path="target/generated-sources/openapi/src/gen/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="ignore_optional_problems" value="true"/>
		</attributes>
	</classpathentry>

Clean Language Server Workspace and the problems are gone.

It would be great to be able to enable this for any "target/generated-sources" folder without the need to set java.import.generatesMetadataFilesAtProjectRoot and manually editing .classpath.

[rubensa]

NOTE: It's curious that for annotations and test-annotations the ignore_optional_problems attribute is automatically set:

	<classpathentry kind="src" path="target/generated-sources/annotations">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="ignore_optional_problems" value="true"/>
			<attribute name="m2e-apt" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/test-classes" path="target/generated-test-sources/test-annotations">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="ignore_optional_problems" value="true"/>
			<attribute name="m2e-apt" value="true"/>
			<attribute name="test" value="true"/>
		</attributes>
	</classpathentry>

[rgrunber]

Interesting! I didn't know about ignore_optional_problems. Definitely works for me.

Only disadvantage is according to IClassPathEntry, it represents a package fragment root (eg. src/main/java) so I don't think we could get as granular as a set of files, or folders (eg. src/main/java/org/example/only/this/subpackage/)

[heyarny]

Any updates on this? files.exclude is hiding the folder altogether and not really hiding all warnings from the problems-tab, which is not what we want. A solution with individual .devcontainer settings would be great.

[rgrunber]

Just a question for those interested in this feature. What should happen when you open a file that is in the "file exclude" list for problems ? If you type something in that file, and it's a compilation error, do you still expect the incorrect tokens to be annotated as errors ? The problems view is linked to this workflow so you can't have the errors show up in the file and not the problems view (as far as I understand). Should the exclude filter for a file only be active when a file isn't open and having focus ?

Are there certain kinds of errors that you specifically want excluded, and others that you never want to exclude (eg. compilation errors) ?

[rubensa]

I'll say that this should work just as annotations and test-annotations that automatically set the ignore_optional_problems attribute for the classpathentry for the generated source files (so really no need to explicitly set files to ignore).

That said, if there is a way to explicitly set what files should be ignored for error check... that should be obeyed... no error should be reported for those files.

Again, that said, I'll suggest to provide both a way to ignore all errors for specified files and another way to ignore only optional problem for specified files (so it would work as the annotations and test-annotations but manually specifying the files instead of automatically recognizing that the files are auto-generated).