Sonar Community Roundup, Oct 3 - Oct 9

Sonar Updates
1

We’ve wrapped up another big week here at Sonar. Below are this week’s release highlights.

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

SonarQube Cloud

SonarQube Server / Community Build

  • @rmontag_ap provided a detailed report that binding an existing project to Bitbucket Data Center fails with a 400 in 2026.5.1, and @yoooooooooooooo confirmed it used to work. You’re right that the behavior changed. Binding now intentionally requires your own personal access token so you always act within your permissions on the repository, but the UI doesn’t make that clear. SONAR-32667 will have the binding flow prompt for the token and explain why it’s needed. Thanks for sharing your workaround, too!

Rules & Languages

  • java:S3065 misses reversed Math.min/Math.max bounds when they’re double or float constants, as @marktiwnzhao showed with a crisp reproducer. Here goes JAVASE-263 to extend the rule to floating-point values. Nice catch!

  • Slow local runs of the SonarJS ESLint plugin led @lukpsaxo to dig into the implementation of javascript:S5914 (sonarjs/no-trivial-assertions), where they found that the file’s dependencies were being resolved over and over for every node. They went above and beyond by opening a PR adding a per-file cache, and we cherry-picked their commits into a change that’s now merged. Faster assertion rules will roll out with upcoming releases, and we owe it all to you!

  • cpp:S3743 asks to remove a noexcept clause when the only throw sits inside an if consteval block, where it can never run at runtime. Thanks @bouteillon for the clear example! We’ve reproduced it and we’re on it.

  • cpp:S5271 suggests [[noreturn]] on functions that end in assert(false), even though assertions can be compiled out. You’re right @bers, and we plan to stop raising this rule when its conclusion depends on assert. Thanks for the sharp eye!

  • java:S5411 raises a false positive on unannotated Boolean methods in JSpecify @NullMarked classes, where the return type is non-null by default. @jiwons even pinpointed the likely cause in the rule’s implementation. Insightful! We’ve added it to our backlog.

  • javabugs:S2259 flags a possible NullPointerException on a lazy getter that can never return null. Welcome to the Community, @blazkosi, and thanks for the reproducer and for checking existing tickets first! You’re right, it’s a false positive, and 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!

3 Likes