Fix #15079 FP syntaxError for C-style cast before scope operator

[autoantwort]

https://trac.cppcheck.net/ticket/15079

The check added in a294079 (#15060) reports every ) followed by :: unless the ( belongs to a control flow keyword or decltype. That also rejects valid code, and the whole file is skipped:

(void)::CloseHandle(h);
HBITMAP old = (HBITMAP)::SelectObject(dc, bmp);
new (p) ::N::T;

Now the error is only reported when the parenthesis follows a non-keyword name, the unknown macro case (CL_NS(util)::X, void C(abc)::f()) the check was added for.

On our code base this regression dropped the number of findings from 17401 to 9193 (10 files with casts like the ones above, one of them a widely included header). With this change the count is back to the previous level.

This PR was created by Claude Code (an AI coding agent) on behalf of @autoantwort.

🤖 Generated with Claude Code

[danmar]

This is an AI review take it with a grain of salt. Please feel free to reject it by clicking on Resolve button

Whether a token is a keyword depends on --std (TokenList::isKeyword() uses Keywords::getAll(standards.cpp)). With --std=c++03, decltype is a plain name, so this now gives a false syntaxError:

$ cppcheck --std=c++03 dt.cpp
dt.cpp:3:12: error: syntax error [syntaxError]
decltype(s)::type i;

The old code avoided this with prev->str() != "decltype". Maybe keep that, e.g. && !prev->isKeyword() && prev->str() != "decltype".

[danmar]

This is an AI review take it with a grain of salt. Please feel free to reject it by clicking on Resolve button

In this project tests usually reference the ticket number, e.g. // #15079.

[danmar]

I feel that the parser and checker code is quite sensitive, so it’s important that changes are made very carefully and that we consider how they might affect other edge cases or existing behavior.

For this kind of code, I personally prefer that we work through the problems manually and carefully. My concern is that AI-generated fixes don’t necessarily approach the problem with the same level of care or consideration for all the possible consequences.

I also believe that working through these issues manually will help strengthen your understanding of the code and increase your learning curve over time. I want to build as strong team as possible with engineers who have a deep understanding of the code and our philosophy.

That said, I do appreciate that you were transparent about the fact that the fix was made with the help of AI. I think that kind of transparency is valuable.

To get a better sense of how this PR works in practice, I think it would be useful to run test-my-pr.py. I would probably run it against a couple of thousand projects to see whether the change behaves correctly across a broader range of cases.

[danmar]

I will allow this one. looks good to me.