SonarCommunity Roundup, May 2 - 8

Sonar Updates
,
1

First an administrative note: I mentioned a couple weeks ago that Community email subject lines would be simplifying soon. That feature became available yesterday and I turned it on immediately. So your inbox may look a little different now: hopefully easier on the eyes, but just as valuable!

It’s been a big week in the Community for feedback this week, with lots great input on all fronts. So now, like every week, we’d like to take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback to drive continuous improvement in our products.

SonarQube for IDE

  • @rebb and @Districh reported that SonarQube for Visual Studio stopped analyzing files in projects spanning multiple drives, a regression in version 9.7. After extensive debugging and multiple test builds, a fix using absolute paths is being finalized as an opt-in setting. Thanks to both of you for the patience and thorough testing through many iterations!

  • A regression in the latest SonarQube for IDE releases caused C# analysis to stop detecting issues after files were reopened. @Leopold_Lerch spotted it first, and @saariniemi, @MTurnhoutGt, and @BartNucor helped confirm the scope across VS Code, Rider, and Visual Studio. We declared an incident and shipped fixes across all IDE flavors. Thanks to everyone who reported in!

  • @MrMikeJJ and @FilRip flagged that SonarQube for Visual Studio became unusable when a certificate revocation check failed, triggering an infinite retry loop that froze the UI. Both helped validate intermediate builds, and the proper fix shipped in version 10.2.3. Thanks for the fast turnaround on testing!

SonarQube Server / Community Build

  • @Jonah_IntegraDev noticed that bulk-changing issue assignees stopped working in 26.4.0, with the assignee dropdown appearing empty despite successful API responses. SONAR-27732.

  • @Scott pointed out that building SonarQube from source is broken. Again. This time due to unpublished scanner-engine dependencies after a recent repo extraction. SCANENGINE-374.

Scanners

Rules & Languages

  • azuredevops:S8263 was flagged as a potential false positive by @HenrikSommer-eng. It turned out to be a true positive, since arguments can pass extra arguments to msbuild that affect execution, but the rule documentation didn’t make that clear. We’ve updated the rule description.

  • @Wiebke reported a false positive from java:S2755 where the recommended setFeature call was already present on the next line. You’re right; the rule needs to recognize more signatures. JAVASE-47.

  • Named .env files like local.env and remote.env weren’t being picked up by secrets detection, as @HansvdLaanNedap discovered, because we were only looking at “dotfiles.” We’ll start automatically scanning *.env files too, rolling out with upcoming releases.

  • java:S1942 currently only flags fully qualified class names when the class is already imported, but @MortenHindsholm pointed out it should also flag cases where an import would be cleaner. We agreed there’s room for improvement when no naming collision exists. Thanks @jilles-sg for the insightful edge case analysis! SONARJAVA-6359

  • @Emilyaxe reported that java:S1144 raises a false positive when a private method is referenced via @MethodSource using a fully-qualified class name. SONARJAVA-6346.

  • @Emilyaxe also flagged that java:S1128 reports static imports from the same class as “unused.” The behavior is correct (same-class statics don’t need importing), but the message does need updating. It should say “redundant” rather than “unused”: SONARJAVA-6288.

  • go:S1313 should exempt addresses in the 3fff::/20 documentation subnet (RFC 9637), as @jqueuniet pointed out. We already exempt the older 2001:DB8::/32 subnet, and we’ll add this one too.

  • java:S5194 raises a false positive on switch expressions where every branch throws, as @vtintillier reported, making the suggested fix impossible to apply. SONARJAVA-6362.

  • @asm0dey spotted that the quick fix for java:S6880 silently changes null semantics: instanceof is null-safe, but the generated switch expression without a case null arm throws a NullPointerException. Nice catch! SONARJAVA-6341.

  • @asm0dey also reported that the quick fix for java:S6877 produces uncompilable code on constant cases. SONARJAVA-6361.

Thanks again to everyone mentioned here - and to anyone we may have missed - for your ongoing contributions in making this community stronger and helping us improve Sonar products.

If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!

 
Ann

2 Likes