* Fix misra 8.7 false positives on single function usage
When there is a single usage of a function, we should first check if the
file it is used in, is the same one it was defined in. When this is not the
case, there is no violatior to be reported.
* Fix misra rule 5.9 false positives for exception
The exception for rule 5.9 described in the guidelines allows for
multiple definitions of internal linkage obejcts when these regard a
static inlined function defined in the same header file.
* Fix neglecting of inline keyword flag upon simplifications
When the inline keyword is being "simplified" and the inline flag is
degated to the next token. However, this information might be lost if the next
token itself is simplified/deleted in a futher pass. Therefore, we must
propagated the flag to all the next named tokens, so we can make sure the
function name token itself is tagged with this property.
* add tests for misra addon rules 8.7 and 5.9
* Fix the ability to recognize return types when simplifying attributes.
When parsing attributes to remove them, we have to allow for
the case where the return type of the function that follows
the attribute has a namespaced C++ type, like foo::bar .
That means that :: has to be recognized as a valid token.
Fix this in simplifyAttribute, and add tests for this as well.
* Don't simplify template for class names in declarations
Without the patch, the test would give:
```
Expected:
namespace foo { class Bar ; } class Baz ; class C : Baz { } ;
Actual:
namespace foo { class Bar ; } class Baz ; class foo :: Bar : Baz { } ;
```
* Use valid code in test case
Previously only a single regular label before a compound statement was
allowed in simplifyAddBracesPair() after if/switch/do/while/for.
This patch adds support for:
* case-labels;
* labels before a single statement;
* labels before try/catch blocks;
* multiple consecutive labels.
Additionally the code for skipping a case label was extracted into a
separate function from simplifyLabelsCaseDefault() and reused in
simplifyAddBracesPair().
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.
Fix faulty removal of parenthesis when "]" is followed by parenthesis
with a number inside, for example when calling a function pointer in
an array or (perhaps more common) in c++, calling operator ( on an
element in an array.
Fixes#8875 where such wrong simplification lead to a FP with too many
bits shifted due to "<<" was interpreted like a shift operator rather
than a stream output.
* fix some hangs in daca from uninstantiated template classes derived from itself
* remove assertions
* fix another simplifyUsing hang
Co-authored-by: Robert Reif <reif@FX6840>
* clang_tidy.cmake: added clang-tidy-11 to list of executables to look for
* .clang-tidy: disabled warnings we are (currently) not interested in
* fixed clang-tidy warnings
The template simplifier works well enough now so cleanupAfterSimplify is
no longer necessary. In fact cleanupAfterSimplify was introducing a bug
which improperly simplified C++ style casts.
Bugs should be exposed and fixed properly rather than just hiding them.
Co-authored-by: Robert Reif <reif@FX6840>
* Tokenize: Set varId for variables in enum
Set varIds in enum values. It was previously disabled in 5119ae84b8
to avoid issues with enums named the same as global variables. Take care
to only set varids to variables used to set the value of an enumerator,
not the enumerator itself. This is somewhat complicated by the fact that
at the time this happens, astOperand1(), astOperand2(), astParent() etc
are not set. The current implementation is not perfect, for example in
the code below, y will not have a varid set, but x and z will. This is
deemed sufficient for now.
int x, y, z;
enum E { a = f(x, y, z); };
* Fix#9647: Value of enums with variables as init values
C++ allows enum values to be set using constexprs, which cppcheck did
not handle before. To solve this, add a new pass to valueflow to update
enum values after global consts have been processed. In order to do so,
I moved all settings of enum values to valueflow. After setting the enum
values, we need another call to valueFlowNumber() to actually set users
of the enums.
There is still room for improvements, since each pass of
valueFlowGlobalConstVar() and valueFlowEnumValue() only sets variables
that are possible to set directly, and not if setting the value of a
variable allows us to set the value of another. For example
constexpr int a = 5;
constexpr int b = a + 5;
enum E { X = a };
constexpr E e = X;
Here both b and e will not have their values set, even though cppcheck
should be possible to figure out their values. That's for another PR
though.
This was tested by running test-my-pr.py with 500 packages. The only
difference was one error message in fairy-stockfish_11.1, where cppcheck
now printed the correct size of an array instead of 2147483648 which I
assume is some kind of default value. In that package, using a constexpr
when setting enum values is common, but as mentioned, there was no
change in the number of warnings.
chrchr-github
José Martins
Daniel Marjamäki
Oliver Stöneberg
Paul Fultz II
Chris Lalancette
KenPatrickLehrmann
Robert Reif
dummyunit
keinflue
DGarry82
Ken-Patrick Lehrmann
Lars Even Almaas
Tetrix
Rikard Falkeborn
PKEuS
Robert Reif
Simon Martin
orbitcowboy
uhziel
Armin Müller