We are happy to come to you with some cutting-edge new rules and improvements.
We added a set of new rules focusing on C++20 coroutines: S6184: Coroutines should not have too many lines of code S6192: Cyclomatic Complexity of coroutines should not be too high S6193: Coroutine names should comply with a naming convention S6194: Cognitive Complexity of coroutines should not be too high S6365: Use symmetric transfer to switch execution between coroutines S6366: Use conditional suspension to resume current coroutine S6367: Thread local variables should not be used in coroutines S6369: Coroutine should have co_return on each execution path or provide return_void S6372: “await_suspend” should accept type-erased “coroutine_handle” when it uses it in a generic way S6391: Coroutines should not take const references as parameters
We also groomed a few preexisting rules to make them even less noisy and more accurate. All the details are available in the release notes.
All this is already available on SonarCloud.io and will be available with SonarQube 9.3 starting from Developer Edition and in SonarLint soon.
These rules will be useful, but as with the other C++20 oriented rules, I suggest using feature test macros. macOS/Xcode do not currently implement all coroutine features, as is the case with all of the new rules which suggest using the std::ranges::* versions of the various algorithms.
Coroutines can be checked with the __cpp_impl_coroutine and __cpp_lib_coroutine macros respectively, similar to cpp_lib_ranges which would prevent all of these warnings on current AppleClang.
The feature-test macros were written because compiler vendors will not implement C++20/23 all at once, so even though I have the C++20 flag set it’s useful to know what may be used/required to prevent incorrect assumptions, e.g. all of C++20 is understood by a particular compiler.
In contrast to the rule mentioned in your other related post, these rules will only trigger if you are currently using coroutines in your code, therefore they are not suffering from that issue.
This issue only affects rules suggesting to evolve existing code to use a new feature, which might not be supported by some compilers.