Fixing issues

Whether your issue is about a potential security problem, considered to be a bad coding practice, or a more serious logic error, fixing issues usually involve changes to the code. SonarLint’s issue messages contain useful information about how to fix the potential problem and include a rule description so that you can learn more about why the issue is reported. 

SonarLint for IntelliJ offers multiple ways to Investigate issues and fix problems in your code. Issues are most easily fixed by correcting the problem as it is described in the Sonar rule description but it’s not always that simple:

• Check the rule description to understand what the problem is.
• Check the locations tab to see where, if any other places the issue is found.

Double-click an issue in the SonarLint view window to jump to and highlight the code in the explorer. Once the code is highlighted, you have more than one way to expose solutions and suggested quick fixes.

Quick fixes

Some issues have Sonar Quick Fixes which means that with a single click, SonarLint will automatically edit your source code to comply with the rule description; the fix might be applied on several lines in the file. While in the explorer window, type Alt+Enter (or option+Enter on Mac OS), select the lightbulb in the left margin, or hover over the highlighted issue to reveal the tooltip exposing these options: 

1. Fix the issue in the code: Cmd+↓/Ctrl+↓ or double-click the issue report to jump to the line of code in the explorer window. When hovering over the quick fix, a preview is available to show you what will change in the code if you select it.
2. Disable the rule: Go to your IntelliJ Settings > Tools >  SonarLint > Rules and find the applicable rule per language. Some Sonar Rules are disabled by default because they overlap with the built-in IntelliJ code inspection; it doesn’t make sense to report the same issue twice. Note that when running in Connected Mode, rule configurations are fetched from the project’s quality profile and used by SonarLint, overriding any local configuration of your rule selection in the IDE.

Fixing injection vulnerabilities

Taint vulnerabilities are security-related rule issues that are only raised by SonarQube (starting with Developer Edition) and SonarCloud. Due to technical limitations, SonarLint can not raise such issues on local analysis. 

Because the detection of taint issues requires that you are run in Connected Mode, any changes you make to the code must be resolved by your SonarQube or SonarCloud instance. Here are two options to resolve taint issues displayed by SonarLint:

• If you fix the issue locally, commit your code to the server and rerun the analysis on SonarQube or SonarCloud. The new status (of the issue) will show up automatically in your local analysis.
• If you go to the issue in SonarQube or SonarCloud and mark it as fixed, false positive, or won’t fix, in less than 1 minute, the new status will be updated locally.

To investigate injection vulnerabilities (also called taint vulnerabilities) when running in Connected Mode, double-click on the issue shown in the Taint vulnerabilities tab to open the location in the Code Explorer (as you would with other issues). The tooltip and rule descriptions will reveal information about how to fix your issues.

Understanding changes in your code

It could be that the local code does not match with the instance on the server. For example, when you are performing modifications, your code may be different than the server code as analyzed at the time when the issue was detected. In this case, the issue in the Taint vulnerabilities tab has a local code not matching tag, signifying that your local code is a bit different than what it is on the server: the numbered inlay will be grey. In contrast, if the local code matches the issue on the server, it will have a numbered inlay in red.

The solution to managing differences in code depends on your goal at the time. It could be that you are actively updating your local branch in which case you should merge your branch with the main branch and re-run an analysis. It could be that your local branch is behind the main branch, in this case, you can click the Refresh button in the left margin of the SonarLint view window to pull an updated report from the server.

When running in Connected Mode, SonarLint will differenciate known issues from new issues. Known issues are those discovered in a SonarQube or SonarCloud analysis and will have an additional SonarQube or SonarCloud icon in SonarLint. The image below shows a known issue.

Marking issues

In SonarLint for IntelliJ 9.0+ running in Connected Mode with SonarQube 10.2 and newer, it is possible to mark issues as Won’t Fix or False Positive before submitting your code for PR analysis. 

Marking an issue can be applied to both new issues and known issues. Marks made on known issues will be reflected on the SonarQube or SonarCloud server within a few minutes; marks made on new issues will be reflected on the server when a new analysis is run; in version 9.1, marking new issues is not yet possible when bound to a SonarCloud project. The option to mark an issue will not appear if you are connected to an unsupported version of SonarQube or SonarCloud.

You can find the Mark Issue as… action in four locations:

1. Right-click on an issue in the Current File tab and select Mark Issue as…
2. Select an issue in the Current File tab to open the rule description in the Rule panel, then select the Mark Issue as…
3. Hover over your issue in the code editor to bring up the actions menu, then select SonarLint: Mark Issue as…
4. Apply an intention action with your cursor over the issue, then select SonarLint: Mark Issue as…; clicking on the lightbulb will reveal the same intention action

Requirements for marking issues

• SonarLint for IntelliJ 9.0.
• Running in Connected Mode with SonarQube 10.2 or newer. When bound to a project in SonarCloud, it is possible to mark known issues, those already found by a SonarCloud analysis.
• In SonarQube, the Administer Issues permission must be granted to the user(s).

This feature is not supported for security hotspots. It is possible to mark injection vulnerabilities from IntelliJ but it’s not possible to reopen them locally. Please see the dedicated pages for fixing each of those each issue types.