this, and commenting out line 8 breaks compilation#include <iostream>
class User
{
public:
friend std::ostream& operator<<(std::ostream& os, const User& user)
{
const auto id = user.id;
os << "User " << id;
return os;
}
private:
const int id = 101;
};
int main()
{
std::cout << User() << std::endl;
}
Hello @bers,
Thank you for reporting this.
Could you please confirm the exact SonarQube Server version you are using? This is relevant because the CFamily implementation of rule cpp:S1117 was improved in SonarQube Server 2026.1.
One of the improvements specifically addresses cases where a friend function defined within a class has a parameter or local variable with the same name as a non-static class member. Since a friend function is not a member function, it cannot access non-static fields through an implicit this object. The updated rule therefore no longer reports these cases as field shadowing.
Your operator<< example appears to match this scenario. If you are using a version earlier than 2026.1, upgrading may resolve the issue. If you already use 2026.1 or a later version and still see the issue, please share the exact version.
Best regards,
Stevan
We’re on SonarQube IDE v10.2.3.16761, and in the web IDE I see “Data Center Edition v2026.1 (119033)”
Hi @bers
Thanks for the version details. Your SonarQube Server 2026.1 instance uses CFamily 6.77, which predates the fix for this S1117 false positive. The fix was released in CFamily 6.78 and is included in SonarQube Server 2026.2.
I also verified the example with the latest analyzer on Compiler Explorer, where the issue is not reported.
Upgrading the SonarQube Server instance to 2026.2 or later should resolve the false positive in server-side analysis.
Your screenshot shows the issue in the IDE though, which is unexpected because SonarQube for IDE / Visual Studio 10.2.3 should bundle a newer CFamily analyzer that contains the fix. Could you confirm whether this is a server issue opened in the IDE, or share the SonarQube for IDE analysis logs so we can verify which CFamily analyzer version performed the local analysis?
Thanks! We’re on LTA, but good to know it will be fixed in the next one.
I even updated to 10.7.0.17183 and the issue remains, locally (in connected mode).
How can I do this? I copy-and-pasted the MWE above into an (existing) cpp file and see the issue, so it cannot really be a specific issue registered on the server.
Does SONAR send cpp files to the server for analysis, in connected mode?
What do you need exactly? I already set the SONAR extension’s logging level to verbose and checked the “SonarQube” output, and I don’t see any hint of CFamily version numbers. (I do see a couple entries specific to my company that I would not like to share here, so I am not attaching the whole output.)
I was thinking maybe you were using the “Open in IDE” feature of SonarQube Server: Fixing issues | SonarQube Server | Sonar Documentation
But clearly you’re not.
Sonar does not send cpp files to the server for analysis in connected mode.
To get to the bottom of the issue, could you generate a reproducer? You can follow the instructions in Troubleshooting | Visual Studio | Sonar Documentation
The reproducer contains everything needed to reproduce the issue as well as detailed logs of the analyzer. If you don’t want to share it publicly, feel free to DM me.
I sent you the reproducer by DM. Note that the issue disappears from the IDE as soon as I enable add the "sonar.cfamily.reproducer" property; and it comes back once I remove that again.
In the output, I see
[ThreadId 738] [SLCore] [sonarlint > sonarlint-analysis-scheduler] Error executing sensor: 'CFamily'
[DEBUG] [ThreadId 738] [SLCore] [sonarlint > sonarlint-analysis-scheduler] java.lang.IllegalStateException:
A file named "sonar-cfamily-reproducer.tar.xz" has been generated to help the problem investigation.
Please contact SonarSource support providing the following file to help improving the analyzer:
C:\Users\xxx\AppData\Local\SLVS_SLOOP\workDir\.sonarlinttmp_5024513312493125206\10550141585227638605\sonar-cfamily-reproducer.tar.xz
at com.sonar.cpp.plugin.SonarLintSensor.createReproducerArchive(SonarLintSensor.java:147)
at com.sonar.cpp.plugin.SonarLintSensor.execute(SonarLintSensor.java:111)
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:194)
at org.sonarsource.sonarlint.core.analysis.container.analysis.sensor.SensorsExecutor.lambda$executeSensor$1(SensorsExecutor.java:102)
at org.sonarsource.sonarlint.core.commons.tracing.Trace.startChild(Trace.java:63)
at org.sonarsource.sonarlint.core.analysis.container.analysis.sensor.SensorsExecutor.executeSensor(SensorsExecutor.java:102)
at org.sonarsource.sonarlint.core.analysis.container.analysis.sensor.SensorsExecutor.executeSensors(SensorsExecutor.java:93)
at org.sonarsource.sonarlint.core.analysis.container.analysis.sensor.SensorsExecutor.execute(SensorsExecutor.java:81)
at org.sonarsource.sonarlint.core.analysis.container.analysis.AnalysisContainer.doAfterStart(AnalysisContainer.java:122)
at org.sonarsource.sonarlint.core.commons.tracing.Step.executeTransaction(Step.java:42)
at org.sonarsource.sonarlint.core.commons.tracing.Trace.lambda$startChildren$0(Trace.java:76)
at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Unknown Source)
at java.base/java.util.stream.ReferencePipeline$Head.forEach(Unknown Source)
at org.sonarsource.sonarlint.core.commons.tracing.Trace.startChildren(Trace.java:76)
at org.sonarsource.sonarlint.core.plugin.commons.container.SpringComponentContainer.startComponents(SpringComponentContainer.java:183)
at org.sonarsource.sonarlint.core.plugin.commons.container.SpringComponentContainer.execute(SpringComponentContainer.java:164)
at org.sonarsource.sonarlint.core.analysis.container.module.ModuleContainer.analyze(ModuleContainer.java:77)
at org.sonarsource.sonarlint.core.analysis.command.AnalyzeCommand.doRunAnalysis(AnalyzeCommand.java:198)
at org.sonarsource.sonarlint.core.analysis.command.AnalyzeCommand.doExecute(AnalyzeCommand.java:148)
at org.sonarsource.sonarlint.core.analysis.command.AnalyzeCommand.execute(AnalyzeCommand.java:139)
at org.sonarsource.sonarlint.core.analysis.command.AnalyzeCommand.lambda$execute$0(AnalyzeCommand.java:131)
at org.sonarsource.sonarlint.core.commons.progress.TaskManager.runExistingTask(TaskManager.java:47)
at org.sonarsource.sonarlint.core.analysis.command.AnalyzeCommand.execute(AnalyzeCommand.java:130)
at org.sonarsource.sonarlint.core.analysis.AnalysisScheduler.executeQueuedCommands(AnalysisScheduler.java:81)
at java.base/java.lang.Thread.run(Unknown Source)
But maybe the reproducer is still okay.
Thanks for the reproducer.
As I also replied to you in DM, I found the reason why a version of the cfamily analyzer different from what I expected is being used.
Turns out, the cfamily analyzer is not embedded in the SonarQube for IDE Visual Studio extension but it is instead downloaded on-demand. In connected mode, the analyzer is downloaded from the SonarQube Server to which you are connected, which we know has the old cfamily analyzer that doesn’t have the fix for S1117.
Therefore, this problem should be solved once you upgrade your SonarQube Server.
Kind regards
Thanks for the confirmation! So when I asked whether the cpp is uploaded to the server, I wasn’t so far off from the truth. It’s just the other way around, the server is downloaded to the cpp 