Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for excluding files from the problem tab #2150

Closed
FieteO opened this issue Oct 5, 2021 · 15 comments · Fixed by eclipse-jdtls/eclipse.jdt.ls#3218 or #3723
Closed

Allow for excluding files from the problem tab #2150

FieteO opened this issue Oct 5, 2021 · 15 comments · Fixed by eclipse-jdtls/eclipse.jdt.ls#3218 or #3723

Comments

@FieteO
Copy link
Contributor

FieteO commented Oct 5, 2021

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.

Cluttered 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
Copy link
Contributor

snjeza commented Oct 6, 2021

@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
Copy link
Contributor Author

FieteO commented Oct 7, 2021

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
Copy link
Member

rgrunber commented Oct 7, 2021

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
Copy link
Contributor Author

FieteO commented Oct 11, 2021

@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
Copy link
Member

rgrunber commented Oct 12, 2021

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
Copy link
Contributor Author

FieteO commented Oct 12, 2021

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
Copy link
Contributor Author

FieteO commented Oct 12, 2021

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
Copy link
Member

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
Copy link

rubensa commented Sep 14, 2022

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
Copy link

rubensa commented Sep 14, 2022

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
Copy link
Member

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
Copy link

heyarny commented Jun 13, 2024

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
Copy link
Member

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
Copy link

rubensa commented Jun 17, 2024

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).

@rgrunber
Copy link
Member

rgrunber commented Jul 30, 2024

This should be resolved with "java.diagnostic.filter": [ , ... , ] which should take a list of string patterns. Any matching file will be excluded from having diagnostics published.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment