* valueflow: remove unused variable known
since e4677ae640 will trigger :
lib/valueflow.cpp:506:20: warning: unused variable 'known' [-Wunused-variable]
const bool known = (parent->astOperand1()->hasKnownValue() ||
* templatesimplifier: cleanup
since 48c960f56c showing:
lib/templatesimplifier.h:279:16: warning: private field 'mTokenizer' is not used
[-Wunused-private-field]
Tokenizer *mTokenizer;
* split CheckNullPointer::arithmeticError() into
* CheckNullPointer::pointerArithmeticError() and
* CheckNullPointer::redundantConditionWarning()
* Additional errorlist entry:
```XML
<error id="nullPointerArithmeticRedundantCheck"
severity="warning"
msg="Either the condition is redundant or there is pointer arithmetic with NULL pointer."
verbose="Either the condition is redundant or there is pointer arithmetic with NULL pointer." cwe="682"/>
```
This fixes issue in:
```cpp
void f()
{
char stack[512];
RGNDATA *data;
if (data_size > sizeof (stack))
data = malloc (data_size);
else
data = (RGNDATA *)stack;
if ((char *)data != stack)
free (data); // <- data is not stack
}
```
It seems the `ProgramMemory` can't handle two known values(such as int and tok) together. So instead `ValueFlowAfterAssign` runs `ValueFlowForward` with tok values and then runs it with the other values.
I sometimes find myself wondering which test cases I have broken when I fiddle with some check (since I then can try running these specific tests in the debugger, or make a small change and see if the tests pass). This PR adds the testclass and the test case names to the file and line number. I took special care to cover the case where an assert would be placed directly in the ```run()```-function, i.e., not inside a test case (from what I could see, no such case exists). If there is no need to handle this case, the code can be simplified (there wouldn't be need for the ```teardownTest()```-function for example).
The exact format for how to print the test name is very much up for discussion.
* Code changes for Token::mImpl optimisation
* Added new TokenImpl optimisation
Moving members to the TokenImpl struct reduces the size of the Token class, which is a fairly significant optimisation. In my testing on Windows with 32-bit Release-PCRE, this change reduced the size of the Token class from 108 bits to 52 bits and reduced run-time of my test case by around 20%.
* Several optimisations
Deleted some code that ran very slowly and did nothing, as there is no need to change a Token's string to null if you are about to delete it.
Added a frontToken to simplifyCalculations to reduce the amount of work it has to do on already-simplified calculations.
Moved template removal to the end of the list as this reduces redundant iteration and saves time.
* Added tok argument to simplifyCalculations
This means callers can avoid unnecessary work if they know which tokens have already been simplified. Passing nullptr indicates the original behaviour (starting from the front of the list).
* Removed mention of member from another change
* Re-added and optimised some code deleted in error
Changing mTemplateInstantiations to a vector avoids the high cost of doing repeated linear searches. Changing how the code iterates through the array was necessary because the vector can be resized at several points during the loop, which breaks existing references and iterators.
* Changed mTemplateInstantiations to a vector
This is an optimisation that makes repeated linear searches of this collection significantly faster.
Also added a copy constructor to TokenAndName so code can make copies of these objects to keep a reference if a vector gets resized.
* A cleaner optimisation to removing template tokens
This reverts the previous change to made mInstantiatedTemplates a vector and the iterator changes to support this, and makes mTypesUsedInTemplateInstantiation so the eraseTokens logic can be unified.
* Reverted vector to list
Also made mTypesUsedInTemplateInstantiation a vector of TokenAndName objects so it can share the same logic as the other members.
* Added member for template simplifier pointer
This can be used more efficiently than marking Tokens with a flag and then searching through all templates to find the one that matches.
* Turned loop inside out
This means we only have to iterate through the std::list once. std::list is very expensive to iterate through.
* Latest code from danmar and fixed optimisations
In particular I have optimised simplifying template instantiation names as this was incredibly slow because of the number of times it had to iterate through the template instantiation list. Previous optimisations to this weren't very effective and broke some edge cases.
* Added changes from danmar
Made mExplicitInstantiationsToDelete a vector of TokenAndName to be consistent with the rest of the members, which are cleaned up very efficiently.
* Tokens can have many templateSimplifierPointers
* templateSimplifierPointers must be kept in sync
Daniel Marjamäki
Carlo Marcelo Arenas Belón
ivangalkin
IOBYTE
Paul Fultz II
amai2012
Oliver Schode
rikardfalkeborn
orbitcowboy
Sebastian
rebnridgway