It appears that the new [[likely]] and [[unlikely]] attributes in C++20 are placed exactly in the position depicted in the above code snippet, which appears to interfere with the detection of this rule.
This was reported in SonarQube version 9.6
Also worth pointing out, the false positives appear to be triggered on later code, after the closing brace, presumably because the scanner misinterprets the attribute as a structure that that is part of the if statement in a way that causes a parsing failure. Except there was no parsing failure in the analysis where this false positive was reported
Thank you for this example. We recently fixed a similar issue with [[likely]] in a switch… But we need to fix it with if too!
Since you seem to care about the underlying reason for this problem, I’m going to share technical explanations.
There is no parse error, [[likely]] is correctly parsed. The problem is that without [[likely]], the if has a child node which is the compound statement, so far so good.
With [[likely]], the child of the if is something that represents the attribute, and in turn, this child node has a child which is the compound statement. You can see it for yourself on compiler explorer.
So our rule that looks at the nature of the child of an if needs to be updated to “bypass” this intermediate attribute node.