I would appreciate if you can try to merge this even though the mingw is not added yet.
And we can tag a 1.6.1 asap with mingw.

there are users that are eager to start using cppcheck with the performance improvement even if it is a dev-version.

and I am eager to integrate simplecpp so we can see what daca says :-)

I would appreciate if you can try to merge this even though the mingw is not added yet.
And we can tag a 1.6.1 asap with mingw.

I reckon the MinGW issue has always been there but was only exposed by the added tests. I have no looked into it yet. We should try not to release 2.19.0 without it - or at least publish an immediate 2.19.1 with the fixes.

The MinGW CI in Cppcheck also needs to be brought in line with simplecpp which might unearth further issues. And in turn simplecpp probably also needs to add Cygwin. But that would be fine for the next dev cycle.

I published cppcheck-opensource/simplecpp#563 as a fix for the Visual Studio build failures.

I am confused by this:

4>D:\a\cppcheck\cppcheck\externals\simplecpp\simplecpp.cpp(11,1): error C2220: the following warning is treated as an error [D:\a\cppcheck\cppcheck\lib\cppcheck.vcxproj]
4>D:\a\cppcheck\cppcheck\externals\simplecpp\simplecpp.cpp(11,1): warning C4005: 'WIN32_LEAN_AND_MEAN': macro redefinition [D:\a\cppcheck\cppcheck\lib\cppcheck.vcxproj]
  D:\a\cppcheck\cppcheck\lib\check.cpp : message : see previous definition of 'WIN32_LEAN_AND_MEAN' (compiling source file ..\externals\simplecpp\simplecpp.cpp) [D:\a\cppcheck\cppcheck\lib\cppcheck.vcxproj]

Does it somehow try to preprocess simplecpp.cpp and check.cpp into 1 translation unit?

I remember a couple of months ago that we had a static function in simplecpp and got some weird problem when bumping simplecpp because there was a function in cppcheck core with the same name. I thought it was weird but we made a quick hack in simplecpp and added a _ to the name or something like that..

I published cppcheck-opensource/simplecpp#563 as a fix for the Visual Studio build failures.

I wonder if we should try to ensure that check.cpp and simplecpp.cpp are compiled separately instead? Is there something wrong with our cppcheck build..

Does it somehow try to preprocess simplecpp.cpp and check.cpp into 1 translation unit?

No - that simply happens because the Visual Studio project already specifies the define (which is how most projects do it).

I wonder if we should try to ensure that check.cpp and simplecpp.cpp are compiled separately instead? Is there something wrong with our cppcheck build..

Nothing wrong here - just a simple oversight.

I reckon the MinGW issue has always been there but was only exposed by the added tests. I have no looked into it yet. We should try not to release 2.19.0 without it - or at least publish an immediate 2.19.1 with the fixes.

ok. I assume that we can merge the mingw PR into simplecpp in the next 2-3 weeks at least.. and then make a 1.6.x tag in simplecpp soon after that. I do not feel that we will make a 2.19.0 release in october..

No - that simply happens because the Visual Studio project already specifies the define (which is how most projects do it).

alright that sounds reasonable!

callgrind from CI:
56,186,038,977-> 55,434,834,314

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud