Rule cpp:S6197 using <ranges> in C++20

SonarQube Cloud
,
1

Rule cpp:S6197 STL constrained algorithms with range parameter should be used when iterating over the entire range was activated when I switched to C++20.

I like it, it’s nice and useful and all. The only problem is that it triggers on macOS, which doesn’t currently have the <ranges> header. So I have 25/33 warnings telling me to use std::ranges versions of std::any_of, std::shuffle, etc. which doesn’t currently work.

https://sonarcloud.io/project/issues?id=acgetchell_CDT-plusplus&resolved=false&sinceLeakPeriod=true&types=CODE_SMELL

This could be fixed if SonarLint used the feature test macros, e.g.:

#if __cpp_lib_ranges
    if (std::ranges::any_of(two_two,
          [&t_manifold](auto& cell) { return try_23_move(t_manifold, cell);}))
#else
    if (std::any_of(two_two.begin(), two_two.end(),
                    [&t_manifold](auto& cell) { return try_23_move(t_manifold, cell); }))
#endif
    {
      return t_manifold;
    }
2

Hello @acgetchell,

Thank you for your suggestion about more fine-grained activation of rules. I agree that it would be interesting to be more accurate and automatically deactivate such a rule when the compiler cannot understand the upgraded version. I created a ticket to keep track of this issue.

However, the solution you suggest is not going to work directly. For instance, is the code does not include ranges, the macro __cpp_lib_ranges might not be defined, and the rule might be deactivated in places where it could apply. I don’t currently have a solution to automatically detect if the rule could apply or not.

Meanwhile, I suggest that you manually remove this rule (and other similar rules) from your quality profile, and don’t forget to add them back when your compiler/library becomes conformant.

3

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.