* 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.
The value of something in the middle of a condition with mixed || and &&
gives no information on which branch will be taken.
For instance with:
```
int f(int a, int b, bool x) {\n"
if (a == 1 && (!(b == 2 && x))) {
} else {
if (x) {
}
}
return 0;
}
```
We can enter the if part whether x is true or false, and similarly,
enter the else part whether x is true or false. Same thing with the
value of b.
This fixes the following false positive with above code:
```
:4:13: style: Condition 'x' is always true [knownConditionTrueFalse]
if (x) {
^
:2:33: note: Assuming that condition 'x' is not redundant
if (a == 6 && (!(b == 21 && x))) {
^
```
This fixes issues (at least false positives) in code using them.
For instance:
```
unsigned compute(unsigned long long a) {
unsigned num = 0;
while (a > 0xFFFFFFFF) {
a >>= 32;
num += 32;
}
if (a > 0xFFFF) {
a >>= 16;
num += 16;
}
if (a > 0xFF) {
num += 8;
}
return num;
}
```
would give false positive:
```
cppcheck --enable=style sl3.cpp
Checking sl3.cpp ...
sl3.cpp:11:11: style: Condition 'a>0xFF' is always false [knownConditionTrueFalse]
if (a > 0xFF) {
^
sl3.cpp:3:14: note: Assuming that condition 'a>0xFFFFFFFF' is not redundant
while (a > 0xFFFFFFFF) {
^
sl3.cpp:11:11: note: Condition 'a>0xFF' is always false
if (a > 0xFF) {
^
```
In some cases, the condition of the ternary operator is assigned a known
value after the two possible results, and in such cases, we would not
take the opportunity to assign a value to the ternary operator (and to
the other parents in the ast).
This patch adds this capability.
- Remove errorPath of a value on assignment (this fixes enormous memory consumption for code with many subsequent assignments)
- De-virtualized a simple get function that was virtual for no reason
- Cloned function isAliasOf() for single values to avoid instantiating unnecessary std::list objects (
- Replaced a couple of trivial Token::Match/simpleMatch expressions by direct comparison
- Treat enumerators as literal values
Paul Fultz II
Daniel Marjamäki
Rikard Falkeborn
Armin Müller
Oliver Stöneberg
Ken-Patrick Lehrmann
shaneasd
Ken-Patrick LEHRMANN
PKEuS