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).
c++17 fold expressions are simplified to a __cppcheck_uninstantiated_fold__ if they are not instantiated.
c++20 concepts are skipped/removed by Cppcheck and these will be enforced by the compiler.
This only fixes the crash. The templates that are instantiated are
correct but one template is left uninstantiated. Fixing the missing
instantiation is not easy and will be looked at later.
Co-authored-by: Robert Reif <reif@FX6840>
