The allocation invokes some heavy ValueFlow computations. We just want
to generate an unconditional error from the analysis so use some lighter
code which does the same.
`TestThreadExecutorFiles::deadlock_with_many_errors`
Before:
```
real 0m23.517s
user 0m33.453s
sys 0m2.297s
```
After:
```
real 0m5.051s
user 0m6.234s
sys 0m0.422s
```
Added new suppress comments:
- `cppcheck-suppress-begin` and `cppcheck-suppress-end` to remove blocks
of suppression
- `cppcheck-suppress-file` to remove suppression at file level
The suppressions do not interfere with each others. For example, all the
suppressions are matched in the following code:
```c
// cppcheck-suppress-file uninitvar
void f() {
int a;
// cppcheck-suppress-begin uninitvar
// cppcheck-suppress uninitvar
a++;
// cppcheck-suppress-end uninitvar
}
```
Tickets:
https://trac.cppcheck.net/ticket/11902https://trac.cppcheck.net/ticket/8528
Currently the `AddonInfo` is generated and discarded on each addon
invocation. This leads to an unnecessary process invocation for each
addon on each file.
Also if an addon is completely broken we will still perform the whole
analysis only for it to be failed at the end so we should bail out early
if we know it doesn't work at all.
I got error messages while building `cppcheck 2.12.0` for RISC-V Arch
Linux:
```
Testing Complete
Number of tests: 4420
Number of todos: 331
Tests failed: 2
/usr/src/debug/cppcheck/cppcheck/test/testcondition.cpp:4501(TestCondition::alwaysTrue): Assertion failed.
Expected:
[test.cpp:6]: (style) Condition 'o[1]=='\0'' is always false\n
Actual:
[test.cpp:4] -> [test.cpp:6]: (style) Condition 'o[1]=='\0'' is always false\n
_____
/usr/src/debug/cppcheck/cppcheck/test/testcondition.cpp:5014(TestCondition::alwaysTrueContainer): Assertion failed.
Expected:
[test.cpp:5]: (style) Condition 'buffer.back()=='\0'' is always false\n
Actual:
[test.cpp:3] -> [test.cpp:5]: (style) Condition 'buffer.back()=='\0'' is always false\n
```
I found out the reason is that the testcases were designed for
x86/x86_64 or other `signed char` platforms (i.e. default character type
is `signed char` ), whereareas RISC-V is an `unsigned char` platform,
which causes different behavior in
`lib/valueflow.cpp:valueFlowImpossibleValues`. I'm not sure whether this
error leads from a functional bug, so if you have a better approach to
fix it, please let me know.
Maybe you could reproduce this error on x86_64 platform by setting
`defaultSign = 'u';` in `Platform::set(Type t)`.
chrchr-github
Paul Fultz II
Oliver Stöneberg
Daniel Marjamäki
Swasti Shrivastava
orbitcowboy
Johan Bertrand
moui0