* Fix#11473 FP constVariable with range-based for / #11448 FP constParameter with unused non-const range loop variable
* Fix ValueType / #11188 FP danglingTempReference with auto
* Fix ValueType in range-based for
* Update symboldatabase.cpp
Use case where it gave an issue:
using customComparator = decltype([] (const X& lhs, const X& rhs) { return lhs.CompareTo(rhs); });
std::map<X, int, costomComparator> m;
Co-authored-by: Gerbo Engels <gerbo.engels@ortec-finance.com>
* Fix 9392, but for destructors: out-of-line defaulted destructors skipped everything after
Context:
```
struct S {
~S();
};
S::~S() = default;
void g() {
int j;
++j;
}
```
Everything after `S::~S() = default;` was skipped, so the uninitialized variables in g() weren't found.
Out-of-line destructors are useful e.g. when you have a forward declared unique_ptr in the .h,
and `= default` the destructor in the .cpp, so only the cpp needs to know the header for destructing
your unique_ptr (like in the pImpl-idiom)
* Fix unit test, by correctly fixing 10789
Previous commit broke this test, but also provided the tools for a cleaner fix
* Document current behaviour
* Rewrite control flow
* Fix deleted functions, which skipped everything after
`a::b f() = delete` triggered the final else in SymbolDatabase::addNewFunction,
which sets tok to nullptr, effectively skipping to the end of the stream.
* Remove troublesome nullptr, which skips every analysis afterwards
It was introduced in 0746c241 to fix a memory leak.
But setting tok to nullptr, effectively skipping to the end, seems not needed.
Previous commits fixes prevented some cases where you could enter the `else`.
This commit is more of a fall back.
* fixup! Fix deleted functions, which skipped everything after
`a::b f() = delete` triggered the final else in SymbolDatabase::addNewFunction,
which sets tok to nullptr, effectively skipping to the end of the stream.
* fixup! Fix deleted functions, which skipped everything after
`a::b f() = delete` triggered the final else in SymbolDatabase::addNewFunction,
which sets tok to nullptr, effectively skipping to the end of the stream.
* Make it heard when encountering unexpected syntax/tokens
Co-authored-by: Gerbo Engels <gerbo.engels@ortec-finance.com>
* Fix ValueType for pointer typedef
* Add test
* Don't warn for typedef'd pointers, improve error message
* Fix tests
* Add TODO
* Fix test
* Set isSimplifiedTypedef() for more tokens, add test
* Add test
* Fix#10174 debug: Executable scope 'x' with unknown function
* Format
* Add test for #10198
* Fix#10260 debug: Executable scope 'x' with unknown function.
* Fix#10451 syntaxError with typedef and lambda
* Don't insert union into template argument list, add test
* Format
* Revert "Format"
This reverts commit 8c52d49c8b.
* Format
Follow up to 0093452bed.
Give the proper end to getVariableList, since it might not be bodyEnd.
Before that, getVariableList would add the same variables in several
unrelated scopes, and all kind of false positive would follow.
For instance, with the case I added in the unit-tests, I had:
```
../code.cpp:15:18: warning: The struct 'is_A' defines member variable with name 'foo' also defined in its parent struct 'is_A_impl'. [duplInheritedMember]
static const int foo = 8;
^
../code.cpp:15:18: note: Parent variable 'is_A_impl::foo'
static const int foo = 8;
^
../code.cpp:15:18: note: Derived variable 'is_A::foo'
static const int foo = 8;
^
../code.cpp:15:18: style: struct member 'has_A::foo' is never used. [unusedStructMember]
static const int foo = 8;
^
../code.cpp:15:18: style: struct member 'is_A::foo' is never used. [unusedStructMember]
static const int foo = 8;
^
```
* 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.
Previously, if an enum value was set to a value unknown to cppcheck, the
next enum value would erroneously be set to the last set value plus one
(or zero, if no enum value had been set before). This partially fixes
Trac ticket #9647, in the sense that it no longer sets wrong values for
these enum values. Further improvements to this would be to set the
correct values instead. It also fixes the false positive mentioned in the
comments in the ticket.
Fix return value types of library functions returning unsigned.
Previously, the valueType of auto x = f() would be signed even if f()
was specified to return an unsigned type.
This fixes#9941, which is a regression in cppcheck 2.2 compared to 2.1.
The regression was introduced in 32df807b22.
Daniel Marjamäki
Oliver Stöneberg
chrchr-github
gerboengels
PKEuS
Paul Fultz II
shaneasd
Rikard Falkeborn
Ken-Patrick Lehrmann
Robert Reif
Tetrix
PKEuS
Wolfgang Stöggl