Sonar Community Roundup, March 21 - 27

Sonar Updates
1

Hi all,

If you’re using Bitbucket to authenticate to SonarQube Server, you want to jump on the patches being released right now. It turns out we’re using a deprecated API for that that will go away on April 15th, which gives us a second reason to celebrate (:upside_down_face:) that day in the U.S. :sweat_smile: It should be fixed in SonarQube Community Build in the 26.4 release, which will be out at the beginning of the month.

And 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 Cloud

  • @ibrahim [reported] that the quality gate status check in Azure DevOps was stuck in “Waiting” (AzureDevOps “SonarCloud/quality gate” status check is not being updated in the pull requests); it turned out his ADO binding values included quote characters which choked our URL validator. We’re going to add validation at configuration time so this is caught before it affects scans.

  • Turning on debug/verbose logging for the SonarScanner for .NET scanner in the Azure DevOps task wasn’t documented clearly, which @Paul_Birtle pointed out. The answer is to put sonar.verbose=true in the task’s extraProperties, and we’ve updated the docs to make that clear.

Rules & Languages

  • @onigoetz flagged that tsconfig.json files containing comments, valid TypeScript syntax since version 1.8, produce parse warnings and false json:S2260 issues. A fix is in progress for the IaC JSON analyzer and we’re going to make sure the JS/TS analyzer handles them properly as well!

  • A regression made C/C++ analysis start crashing on value-dependent code, as @andreisamuta and @siarheimalyshau flagged. A fix is on the way.

  • @riddleit provided a beautifully thorough report tracking down the analyzer version that introduced a crash in javascript:S1874 when tsconfig file ordering changes. JS-1505

  • A NullPointerException killed analysis in java:S2222 for @vxtls when scanning a Java class with a distributed lock fallback. We’re on it.

  • Kotlin taint analysis started hanging — jumping from 3 minutes to over an hour in CI — as @Donald_Renner flagged. @Donald_Renner also shared UCFGs that let us reproduce the issue and identify the cause: a single statement taking an outsized amount of analysis time. A fix is on the way.

  • .js.flow files inside node_modules were being parsed by the ABAP analyzer, which claims the .flow extension, causing scan errors, as @Eman_Harri reported. A fix is coming in the next ABAP analyzer release, and adding sonar.exclusions=**/node_modules/** works in the meantime.

  • Raising pythonenterprise:S7181 on the PySpark row_number function is a false positive, since the function doesn’t accept a window frame specification, making it impossible to satisfy the rule. Thanks @thomas.schouten! A fix has been ticketed.

  • @Corniel flagged that csharpsquid:S3257 raises a false positive for lambda parameters decorated with attributes in MinimalAPI routes. It thinks they’re unused, even though they’re not. We’re on it.

  • Approval testing libraries where approve.* methods throw AssertionError on mismatch get false positives from java:S2699, as @mkutz pointed out. Thanks! We’ll start recognizing approve with SONARJAVA-6208

  • A year ago @Corniel reported false positives on csharpsquid:S3267 for loops that can’t be simplified to LINQ because ref struct types can’t be captured in closures. That got fixed, but not thoroughly; he reported a new variant this week, which we’re going to handle. Thanks, as always @Corniel!

  • @Corniel also suggested new C# rule to add the notnull type parameter constraint when a parameter is always null-checked. @jilles-sg raised a thoughtful counter-argument about cascading constraints that shaped the discussion. We’re tracking it as a potential new rule.

  • A false positive in python:S6546 when new-style union syntax is used directly in an Annotated type hint was identified by @Stephane_Renou. Thanks! We’re on it.

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

4 Likes