Frequently asked questions

[Julien_HENRY]

SonarLint FAQ

Common

How to ask for help?

Please describe your issue with a maximum of details. We will likely ask you for this information and it’s helpful if you include it upfront:

• Your IDE flavor/version/OS: example: Eclipse 2023-09 on MacOSX
• Your SonarLint version:
• Is Connected Mode used (Y/N):
  • If yes, to which version of SonarQube, or is it SonarCloud?
• If you are using the Connected Mode on SonarQube, what are the installed analyzers? You can easily get a list by opening https://<SQ server>/api/plugins/installed in a Web browser.
• Please include the full stacktrace of the error and logs with Verbose output and Analysis logs enabled. See your IDE-specific Troubleshooting page for detailed instructions to get these logs.

Troubleshooting unexpected analysis results (even with Connected Mode)?

1. Some issues might be detected by a third party analyzer:
   Third-party analyzers are not executed in SonarLint. Some issues may be reported in SonarQube by a plugin leveraging a third-party analyzer (PMD, Checkstyle, ESLint, PyLint, …). SonarLint will only run rules from SonarSource analyzers including custom rules extending SonarSource analyzers. Third-party analyzers usually have their own IDE integration, so we have no plan to run them in SonarLint.
2. Your test files might be mistaken as source files:
   Test files can be defined on the server or in the IDE and when running in Connected Mode, these test sources will be used by SonarLint. Each SonarLint flavor has its own way of detecting which file is considered a test file; in SonarLint for IntelliJ, you must define your test files as a Test Sources Root. To define test files on the server, please the SonarQube or SonarCloud documentation to set the scope of your analysis.
3. Some complex rules are not run in SonarLint:
   Due to extensive resource requirements, taint vulnerability and some advanced bug detection rules are ignored by SonarLint. Please check the SonarLint roadmap for a list of features and enhancements on the horizon.
4. Only line-level issues are reported:
   Some rules are able to report issues at the project-level. Project-level issues are not displayed in SonarLint, only in SonarQube and SonarCloud.
5. When analyzing Java files, the analyzer might need some context for some issues to be found:
   In IntelliJ, there is no incremental compilation of the .class files found in the compiler output folder; these are only produced or refreshed when the project is built. The workaround is to simply build your project with the green hammer (when using IntelliJ) in the top-right toolbar. The project should be built on a regular basis to keep the compiled files up-to-date and overcome this known limitation.

I have configured some SonarScanner properties. Are they applied to SonarLint?

No. Scanner properties you may have defined in sonar-project.properties, pom.xml, … (like sonar.sources, sonar.projectBasedir, …) only make sense in command line SonarScanner context. SonarLint tries to use IDE metadata to avoid other configurations. If you want to share some configuration between SonarScanners and SonarLint, like exclusions, or some analyzer properties, the best way is to use connected mode and to set the configuration in the SonarQube or SonarCloud UI.

---

SonarLint for Eclipse

How to get SonarLint for Eclipse logs?

See the SonarLint for Eclipse Troubleshooting docs page.

How SonarLint for Eclipse decides if a file is a test?

There is a regular expression you can configure in SonarLint settings to specify which files should be considered as tests.
Recent Eclipse versions added the concept of test sources (only for Java projects). When available, SonarLint will also rely on it (see the green icon for test folders).

In the end, if you want to know how a file was effectively classified by SonarLint, look at the SonarLint Console with Verbose output, and search for something like:

Starting analysis with configuration:
[
  baseDir: [...]
  workDir: [...]
  extraProperties: {sonar.java.target=1.8, [...]}
  inputFiles: [
    file:/home/julien/Prog/Projects/sonarlint-core/core/src/test/java/org/sonar/api/utils/log/SonarLintLoggerTest.java (UTF-8) [test]
  ]
]

and notice the [test] qualifier after the filename, to indicate SonarLint classified the file as test.

---

SonarLint for IntelliJ

How to get SonarLint for IntelliJ logs?

See the SonarLint for IntelliJ Troubleshooting docs page.

---

SonarLint for VS Code

How to get SonarLint for VSCode logs?

See the SonarLint for VSCode Troubleshooting docs page.

How SonarLint for VSCode decides if a file is a test?

This is based on the file path + name. There is a glob pattern that can be changed in SonarLint settings. By default files are not considered as tests. For example, you can change the pattern to {**/test/**,**/*test*,**/*Test*}