Hello C and C++ folks.
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_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.
Hello again @acgetchell,
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.
Hope this helps,