Hi, I found that the issue described in the Track tickets 9716 and 9728 has not been fully fixed. In particular, the syntax error on the "try" token still appears if the function signature has trailing keywords e.g. a "const" member function.
As an example, running the latest cppcheck on the attached file returns a syntax error on line 20. Since this was supposedly fixed by I used the test code from the related PR as a basis. That code did work, but adding a "const" member function breaks the analysis.
Perhaps this is due to the if (!TokenList::isFunctionHead(tok->previous(), "try")) continue; branch being taken if the ) token from the argument list does not immediately precede the try token. That would explain why a const member function fails while a ctor or a normal member function works.
PS: as a side note, the syntax error disappears if the const member function is implemented inside the class declaration (because then the "try" is not in the global scope), but I am not sure that the parsing is correct in that case still.
Hi, I found that the issue described in the Track tickets 9716 and 9728 has not been fully fixed. In particular, the syntax error on the "try" token still appears if the function signature has trailing keywords e.g. a "const" member function.
As an example, running the latest cppcheck on the attached file returns a syntax error on line 20. Since this was supposedly fixed by I used the test code from the related PR as a basis. That code did work, but adding a "const" member function breaks the analysis.
Perhaps this is due to the
if (!TokenList::isFunctionHead(tok->previous(), "try")) continue;
branch being taken if the)
token from the argument list does not immediately precede thetry
token. That would explain why a const member function fails while a ctor or a normal member function works.PS: as a side note, the syntax error disappears if the const member function is implemented inside the class declaration (because then the "try" is not in the global scope), but I am not sure that the parsing is correct in that case still.
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/13742
Great, thanks! I built the tool after the fix and confirm that I no longer see the issue.