Quick fix to ignore markers on SonarQube related "SuppressWarnings"#1045
Quick fix to ignore markers on SonarQube related "SuppressWarnings"#1045thahnen wants to merge 5 commits into
Conversation
When having a fork of the repository, e.g. to contribute to it, the CFamily
analyzer cannot be downloaded ("-Dskip-sonarsource-repo") since it is closed
source. In this case, running the plug-in would not be possible, neither from
the IDE nor the packaged version.
Eclipse JDT only accepts specific values for the "SuppressWarnings" annotation, that also cannot be extended. For SonarQube analyzers linked to Java (incl. Security, DBD, Architecture) one can use the annotation to suppress rule violations on different levels. Eclipse JDT raising warning markers on these suppressed warnings as "unsupported" is highly annoying and there should be an option to ignore the compiler warning. This adds a quick fix to this warning, that will configure Eclipse JDT to ignore these markers.
This method is not available in the newest version of the Eclipse IDE (SDK to be precise), replace this with a method from the Java Standard Library to be compatible with every (supported) version of the Eclipse IDE.
SummaryThis PR adds a quick fix for Eclipse JDT's "Unsupported @SuppressWarnings" markers that appear when using SonarQube rule keys in annotations (e.g., Three supporting changes enable this: (1) refactoring What reviewers should knowWhere to start: Reviewers should first understand the core quick fix logic in Key architectural decision: The image refactoring exists because Testing scope: Unit tests mock Eclipse JDT APIs and verify that the quick fix: (1) only applies to relevant markers, (2) correctly identifies SonarQube rule keys in marker messages, (3) sets Potential concerns:
|
![sonar-review-alpha[bot]](https://avatars.githubusercontent.com/in/3025063?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
thahnen
changed the title
|
I need to find some time later this week to implement the requested changes by the agent, didn't find the time yet. |
SonarJS 12.5.0.41048 (released 2026-05-18) produces zero diagnostics on trivial JS fixtures in the sonarlint-vscode extension test suite - likely regression introduced by JS-1649 "Enable rules dynamically based on per-file import declarations". Rolling back to 12.4.0.40770 across SonarLint products until a SonarJS fix ships. See also: sonarlint-vscode PR #1045 (revert 0399dd5), sonarlint-intellij PR #1784 (revert 2e0a5c99).
thahnen
changed the title
|
@nquinquenel, it is ready, anyone of you want to pick it up? In case you decide at some point not to apply this PR, at least cherry-pick the fixes regarding |
1 participant
Summary
When using the annotation
SuppressWarningson anything in Java and providing it with a SonarQube-related rule key, the analyzer will ignore violations of that rule in the given scope. In Eclipse this annotation is handled by Eclipse JDT but very strictly: A marker on theWarninglevel is raised for every encountered annotation with a value (or multiple) likejava:S6548. This is due the values allowed for the annotation being hardcoded in the Eclipse JDT implementation - very sub-optimal.This change adds a Quick Fix to the marker that directly configures the plug-in to ignore these makers - not all related to the
SuppressWarningsannotation, only the ones Eclipse JDT deems "unsupported". This Quick Fix is also only applied when Eclipse JDT is present - not raising issues with IDEs without the Java tooling.For this I had to refactor
SonarLintImagesa bit, moving out the parts that rely on more than the "standard" Eclipse imports (bundles) to not carry over the dependencies to theorg.sonarlint.eclipse.jdtbundle (like SonarLint Core).I also added unit tests because everyone prefers unit tests over integration tests. For how this looks like in the UI, please see this screenshot:
Additional Info
This PR also features 2 other commits, one related to one incompatibility being fixed - this cannot be found in the IDE as the code in question is not running in the ITs and the compilation is done against the oldest Eclipse IDE running on Java 11. Only when developing inside Eclipse, the target platform with the latest Eclipse IDE is used (on purpose).
The other commit is simplifying the development on forks or when contributing due to the CFamily analyzer being closed source. I will properly add another commit, separately, at some point regarding the target platforms (since they are also now hidden behind Repox authentication) to make it a bit easier for forks. Not in scope of this PR - the commit provided is just blocking completely.
Limitations
With the Quick Fix I'm covering all the SonarQube rule keys I know of that are relevant to Java (at least present on latest SQ-C and SQ-S/SQ-SB), if you know of more I might have forgotten, feel free to add them to the class, condition and test. Otherwise Next complains about coverage 😛