Currently sub-expressions like decltype(x){} break AST creation for
subsequent tokens in the whole expression. In some cases this triggers
validation checks in validateAst() and analysis on the file stops.
For example, code like this:
int x = decltype(0){} ? 0 : 1;
currently produces internalAstError.
To fix the issue iscpp11init_impl() was changed to recognize { preceded
by decltype(expr) as a start of C++11 brace initialization expression.
The previous fix for the issue (43b58dbc9e) didn't seem to actually fix
it because it added a check for noexcept without a condition, but when
AST is created noexcept always has a condition due to simplification
from "noexcept" to "noexcept(true)" in Tokenizer::simplifyKeyword().
The issue from the ticket couldn't be reproduced neither on 43b58dbc9e
nor on the previous commit, so it is hard to tell whether the fix was
effective or not.
The issue appeared again after a refactoring of AST code in ac67049661.
Test added with the original fix was unable to catch that because it
used testAst() helper function which skips most simplification steps.
To fix the issue we now check for noexcept with a condition and add a
proper regression test that:
1. Uses tokenizeAndStringify() to ensure that all simplifications are
performed before AST is created.
2. Parses the code snippet from the ticket, as having "if (cond)" is
crucial to reproducing the original issue (internalAstError).
Also fix AST creation for lambdas that have both constexpr and mutable
keywords.
Spotted by coverity (as the condition in the `if` part `isArrayVar(tok)`
dereferences tok.
Tok can't be null here, because the condition in the `else if`on line
268 checks that there is a `%var%` following, and
`tok = Token::findmatch(tok->next(), "%var%");` simply gets this `%var%`
token.
Variables declared in the if condition (or in C++17 init-statement) are
visible not only in the if body but also in the else body. But logic in
Tokenizer::setVarIdPass1() handled such variables as if they were
declared in the if body.
As the result they were removed from variablesMap by the time the else
block was parsed and their uses in the else block were either given an
incorrect varId from variables in some outer scope or not given a varId
at all.
This then resulted in false positive unreadVariable errors for variables
declared in the if condition (or init-statement) and used only in the
else block.
Simplification from "else if ..." to "else { if ... }" was moved before
setVarId() to simplify detection for ends of blocks in if-else chains.
When ErrorMessage::callStack elements are serialized to XML they are
saved in the reverse order. But when they read back from XML they are
added at the end of the list. Thus the round trip via XML reverses the
order of ErrorMessage::callStack.
From the user point of view it looks like the usage of the
--cppcheck-build-dir option sometimes (when the file wasn't reanalyzed,
but that is hard to spot) results in incorrect location info for some
diagnostic messages.
Moreover, when the first location matches some suppression rule and the
last doesn't match any (or vice versa), usage of --cppcheck-build-dir
results in some diagnostic messages appearing and disappearing seemingly
at random (again, depending on whether the file was reanalyzed or not).
Daniel Marjamäki
keinflue
dummyunit
Ken-Patrick Lehrmann
DGarry82
Paul Fultz II
Robert Reif
Oliver Stöneberg