As a customer I would like to initiate a discussion, how long we can wait for the support of new language or compiler features to be recognized by the SonarQube analyzers.
a) Features of .NET 6 / C# 10 (Nov. 2021) are still not recognzed in SonarQube 9.9 LTS (Feb. 2023). See this discussion and the GitHub issue with estimated release for autum 2022.
New .NET releases are scheduled every year in Nov, .NET LTS every 2nd year. As least the .NET LTS and their language versions should be coverd in a timely manner.
b) Also Java. For me, it is accepted that not every current release all 6 months is immediately supported. But for the LTS versions I would like to have support near to the JDK release date.
c) Similar the discussions on newer C++ standards, which are scheduled every 3rd year.
For sure, Sonarsource will need time and man power to develop the scanners - but in all examples the drafts of the new language releases are available months in adavance. What is the expected time frame other users do have for support of new features?
As scanners are no longer possible to update in an existing on-premise SonarQube, I’m disappointed that it is announced to support up to C# 11, we still get false code smells for older features (C# 10 and earlier). Personally my expectation would be the support of the of languages LTS which are 3-4 month available before a SonarQube LTS.
Thanks for your post. I appreciate this can be frustrating, we try to support new language features as soon as we can, in reality this varies based on the size and complexity of the features introduced.
As the Product Manager for .NET, I can tell you some more about our goals and why you are still seeing some issues in older C# versions.
At the point of a new .NET release (or very soon after) we aim to release a Scanner for .NET and Analyser that will analyse the new language version without any errors and not raise a large amount of new FPs. Over the next few months we will continue to improve support for new language features in our existing rules. Once that’s done we’ll consider new rules that can help users with the new features.
I appreciate that there are a number of important rules where we still don’t support new language features such as S3900. This is because we have been re-architecting the analyser to use the Roslyn CFG that always supports new language versions, and have built a new Semantic Execution Engine with this. We’re converting our rules and it’s taken longer than we hoped. We’re making good headway and the releases you see over the next few months will see many of these issues, including S3900 resolved. The detection and precision of these rules will be greatly improved and they should automatically support new language versions because they are based on the Roslyn CFG.
I’ll leave it to other PMs to update you on the other languages, this may not be for a few weeks because of Easter holidays.
Thanks Tom for your answer with detailed insights.
It will be good, if this re-architecture supports new language features in the future sooner. But still I (and probably key users of other companies) are currently extemly unhappy as we on the one-hand need tp keep the pressure to upgrade .NET SDK to the latest LTS for security and support considerations, on the other hand when colleagues use also the new feature of the language we have to tell them. please don’t use these features or you’ll get a lot of false positive in SonarQube. It’s a critical point, where SonarQube looses acceptance from developers.
Can you already estimate which version of SonarQube will have the new scanners? Or drop here a line as soon as they are available, please?
Each release of SonarQube will include improvements in this area. In 10.1 (expected in June) we will release the new version of S3900. By the time of the next LTS the conversion to the new Semantic Execution Engine should be complete and all rules will be working with the latest language versions. From then on, fully supporting new language version will be much simpler and should happen around the time of the release. I’ll start sharing more here when there are updates. Thanks for your patience.
Just a quick update to share that we just released a new version of the analyser that addresses some of the issues you’ve been having. You can read more here.
Have a good weekend
I saw the message from Martin Strecker’s comment on the GitHub issue already.