It would be really helpfull if SonarLint could also show the issues found by SonarQube in connected mode. At the moment it’s a bit cumbersome to check for issues just with SonarLint because if you edit a file in Visual Studio and check the SonarLint issues you also have to check via web browser for additional issues found by SonarQube.
I need some clarifications because as far as I know, SonarLint in Connected Mode is supposed to show the same list of issues as the one detected on SonarQube side. The only exceptions are:
- the Security Hotspots because they are not issues but hotspots and there is a dedicated workflow to review them in SonarQube
- the Vulnerabilities raised by the Taint Analyzer (SQL Injection, …) because it’s taking time to raised them and this is not compatible with the real-time philosophy of SonarLint
When you are saying you don’t see the same issues, are they in the 2 categories I mentioned?
no the issues aren’t in that categories you mentioned. For example: I have a file with a Bug(Blocker)
“Out of bound memory access (access exceeds upper limit of memory block)” that is listed on the SonarQube server but not in SonarLint. The project is connected with the SonarQube server project.
and the synchronization of the rules (quality profiles) is working here.
I’m working with Visual Studio 2019 Professional and SonarLint v4.25
I’ve just forgotten to mention that the project is a C++ project.
Thanks for the clarification. For C/C++, only https://rules.sonarsource.com/c/RSPEC-5536 is configured to not run in SonarLint because it needs project level data that we don’t gather when you are on a given file.
So https://rules.sonarsource.com/c/RSPEC-3519 should be executed in SonarLint. I’m changing your post from “New Features” to “Bug”.
If this rule https://rules.sonarsource.com/c/RSPEC-5536 is the only one not to run in SonarLint, then I think there are multiple other rules that also not working in SonarLint in connection mode.
For example: ‘“pthread_mutex_t” should not be consecutively locked or unlocked twice’ rule c:S5486 is shown by the SonarQube server but not in SonarLint. So I suppose there are other bugs(blocker) that also not beeing shown in SonarLint.
Thanks for reporting this issue to us.
Can you please provide us with more information:
- Am I correct in understanding that you’re using Visual Studio?
- Can you please specify your VS version, and what is your SonarLint version?
- Are you in Connected Mode? Can you please verify that you are synced to the correct project in your server?
Also, please open the SonarLint output pane and run an analysis on the file where
c:S5486 is supposed to be triggered. You should see a similar log output:
Loaded settings from "<path-to-your-settings-file>". Using connected mode settings. User-specified settings in settings.json will be ignored. Calculating effective rule settings... Note: the following CFamily rules are not available in SonarLint: cpp:S5536, c:S5536, cpp:S5801, c:S5801, cpp:S5814, c:S5814, cpp:S5815, c:S5815, cpp:S5816, c:S5816, cpp:S5824, c:S5824
Can you please open the file located at
<path-to-your-settings-file> and verify that S5486 is configured to
"level": "On" ?
Also, are you seeing any exceptions in the SonarLint Output window?
I’m using Visual Studio 2019 (v16.7.3) together with SonarLint v4.25 and SonarQube Developer Edition v8.4.1.
The output doesn’t show any issues/exceptions just the same as your example output. My c_settings.json file has the following lines:
and the project is connected to the SonarQube-Server(project).
Here is the output of SonarLint:
Connecting to ‘https://xxxx.yyyyy.com/sonarqube/’.
Using default daemon download URL
Daemon version: 220.127.116.111
Daemon download url: https://binaries.sonarsource.com/Distribution/sonarlint-daemon/sonarlint-daemon-18.104.22.1681-windows.zip
Settings file does not exist at “C:\Users\xxxx\AppData\Roaming\SonarLint for Visual Studio\settings.json”.
Default settings will be used
Loaded settings from “C:\Projects\xxxxxt\trunk\Source.sonarlint\xxxxx_c_settings.json”.
Using connected mode settings. User-specified settings in settings.json will be ignored.
Calculating effective rule settings…
Note: the following CFamily rules are not available in SonarLint: cpp:S5536, c:S5536, cpp:S5801, c:S5801, cpp:S5814, c:S5814, cpp:S5815, c:S5815, cpp:S5816, c:S5816, cpp:S5824, c:S5824
Checking for suppressions…
Finished analyzing C:\Projects\xxxx\yyyyy.c, analysis time: 1,767s
Found 25 issue(s) for C:\Projects\xxxx\yyyyy.c
Number of suppressions found: 1254
Connected to SonarQube ‘22.214.171.124646’.
Thanks for the response @fuzzel.
Everything seems fine and it should be working. Let’s try to narrow it down:
- Can you please try the sample non-compliant code? The issues are raised as expected for me with this piece of code.
- Is the analyzed file a header file? We currently do not support header files in SonarLint.
- If the analyzed file is not a header file, can you please create a reproducer file and share it with me here/via a private message?
the non-compliant sample code doesn’t work for me either. I pasted the code into a cpp file but SonarLint doesn’t find it.
The cpp file is part of a Windows VS project where pthread functions are unknown ofcourse. Does it make a difference?
Yes, your code must be compilable by VS and must use the real library. The issue will never be raised if your code doesn’t compile.
Is the expected issue(the one you see on SonarQube) happen on a header file or a source file?
If you aren’t able to reproduce on a simple example and if the expected issue is on a source file, Please generate a
reproducer fileof the exact same code that triggers an issue on SonarQube. How to generate a reproducer file.
Analysis works differently between SonarQube and Sonarlint. They are two different products. We never aimed to make them the same. We do what makes sense in each context. SonarLint analysis is tuned for an IDE. Nonetheless, S5486 Run on SonarLint. So if the expected issue is on a source file, we can treat this as a false-negative report and fix it.
Thanks for the explanations. If the code must be compileable by VS then it clear that it won’t show the issue because the file in question is for a Linux target that is just added in the VS project but excluded from the VS build. So I think we can close this bug, as it’s not a bug in this case.
However this bug report came from a feature request that the SonarQube findings should also be shown in SonarLint regardless if SonarLint can completely analyze the code.