Make the MISRA addon emit extra warnings for unused arguments placed in
lines other than the function definition. This makes it easier for the
user to find violations.
The MISRA 2012 standard does not say anything about variadic functions
in the definition of rule 2.7. Therefore, these cases should be
considered as false positives.
The example code that reproduces this crash:
```
int misra_8_2_o(
const uint32_t a1,
const uint8_t *const a2
)
{ return *a2 + a1; }
int misra_8_2_p(
const uint32_t a1,
const uint8_t *const a2
);
```
The unit test was not added because it looks like a typo and regressions
are unlikely.
* misra: Fix 8.2 false positives
Fix false positives in rule 8.2 that occurred in cases when we have a
function definition and declaration in the same file.
For example, the following code generated false positives before this
commit:
```
void f(uint8_t * const x);
void f(uint8_t * const x)
{ (void)x; }
```
We need to distinguish the declaration and the definition, so the dump
file generation routine was extended to keep token where the definition
of the function. The analysis in the addon also been improved.
Closes Trac issue: https://trac.cppcheck.net/ticket/10219
This fixes the crash on with struct fields containing unknown types
reported on the forum:
https://sourceforge.net/p/cppcheck/discussion/general/thread/d64551cc55/#5f0f
The suggested patch doesn't handle the cases when there are struct
fields with arrays containing unknown types. So the addon will not
generate warnings in these cases. The problem is that Cppcheck doesn't
generate valueType-pointer information for unknown types in the dump
file. When adding this in symboldatabase.cpp, MISRA addon will generate
a lot of false positives because we depend on the null value of
valueType.
So I suppose it better to left this as is, to don't break the addon for
such rare cases.
If user doesn't create a build directory, it is not possible to run the
addons, because addons are trying to check dump files in non-existent
build directory.