Hi all,
This first week of December has been a relatively quiet one, perhaps because folks have been more focused on cleaning their homes for holiday parties 
than on cleaning their code. 
That makes the reports we did get even more precious, and like every week we want to spend some time saying thanks to everyone who prompted interesting discussions and gave us feedback on Sonar products that will help us continuously improve.
SonarLint
- Deep thanks to @leard, @Tim_Feuerbach, @lvanderlaan, @ziiigzag, @AlexisKyaw and @VaolEr who reported a freeze in SonarLint for IntelliJ. It was caused by a deadlock, and SLI-1203 has already been fixed and released to the marketplace.
- As @photex reported, being prompted to install Node.js when you don’t even want SonarLint for VSCode to analyze the related files is a distracting frustration. Our plan is to bundle Node.js, but in the meantime SLLS-198 will let you mute the message.
- Conversely, @anon67236913 had problems with the Node.js already embedded in SonarLint for Eclipse. In a long-running saga, he first noted problems with it back in September. After much back and forth and log sharing, we were able to create SonarSource/SonarJS#4400 to prevent starting the embedded Node.js if one is provided by the user.
SonarCloud
- @HaroonSaid was having trouble getting analysis to show coverage for his PRs. He eventually tracked it down to a setting in his CI that was interfering with the SCM data needed to properly track new code. It was a great find, and we’re planning to add it to the docs.
- @Sreekarun-S_fortive found that GitHub actions analysis wasn’t properly cleaning up after itself in his self-hosted, Linux agent. We had already fixed it for SonarQube, so we’ll be able to port the change over quickly.
SonarQube
- Switching from one authentication provider to another should be seamless, but @lg2de found that it wasn’t after moving to SAML. It seems our treatment of emails is case-sensitive. That will be fixed with SONAR-21233.
Language and Rule Improvements
- @rcramer found that the noncompliant code example for S6437 wasn’t actually noncompliant. Or at least, no issue was raised. Doh! SONARPY-1579 will fix that.
- @ChristopheS was kind enough not just to report a false positive in S1096, but to also take the time to help us understand why it’s a false positive when we didn’t see it at first. Hat tip, sir. SONARHTML-185 will fix it.
- With a Java-based server and scanner, we’ve long been confident that we were fully platform-independent. Not so, it seems. @skysZhang reported problems analyzing Go on Linux ARM64. SONARSLANG-639 will broaden support to include ARM64 architectures for MacOS and Linux.
- @Kuga2 started an interesting discussion that was sparked by issues raised on his macros. The output was several different ways to approach them.
- @HugoMercierYuc faced a false positive in S2699, which he reported not just with detailed reproduction instructions but also a demonstration repo! We’ll fix it with SonarSource/SonarJS#4459
- S1905 suggests a fix that leads to compile failure. @Ahmed_Ashour was good enough to provide a very neat reproducer. We’ll fix it with SONARJAVA-4734.
Once more, we extend our thanks to everyone mentioned here - and those we may have missed - for their efforts in strengthening this community and enhancing our Sonar products.
Please leave your own recognitions below – whether for another community member or a SonarSourcer who assisted you this week. If there’s someone you think should be acknowledged in next week’s roundup, don’t hesitate to let us know.
Ann, @Colin and @leith.darawsheh