I am not sure if that will be fixed soon. I know what to change but there is some logic which needs to be tested and gives me headaches. I am fixing everything around it though.
Last edit: Oliver Stöneberg 2025-11-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since it seems there will be no fixes for the issues introduced by https://github.com/danmar/cppcheck/pull/7658 it needs to be reverted before release (I will post a PR if nothing happens until the end of the week).
Since it seems there will be no fixes for the issues introduced by https://github.com/danmar/cppcheck/pull/7658 it needs to be reverted before release (I will post a PR if nothing happens until the end of the week).
I guess we can revert it and then the changes can be polished and broken up and resubmitted.
It's still a draft PR. Do I understand correctly that compilation and linking works fine currently? But you want to utilize C++17 better? In that case I don't see this as that critical.
I would like to release soon. Customers are waiting for some of the bug fixes. What more do you feel we need to fix before the release? Imho getting latest simplecpp fixes into cppcheck should be pretty high prio.
I can help out and I can ask ludvig, oleksandr and swasti to work on some tasks if there are suggestions..
Last edit: Daniel Marjamäki 2025-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
regarding https://github.com/danmar/simplecpp/issues/556 / https://github.com/danmar/simplecpp/pull/475
I think it will be fine to release it without having the MinGW CI in-place and the known issues fixed. It only affects simplecpp since it is not hooked up in Cppcheck yet so the scope is also limited. Since the current CI does not fail and we already missed earlier issues it is obviously not a primary (or possibly even secondary) platform. It should definitely be fixed for the future 1.6.x/2.20 release (we should backport it for a patch release though). I am also pretty sure adapting the MinGW CI in Cppcheck will unearth more issues.
No idea where we are at in terms of the CMake stuff.
I don't actually understand the details of the changes nor your objections. But I think your objections was ignored too quickly when you were not able to participate. There was a sense of urgency as there is a lot of flux and therefore hard to keep the PR up-to-date.
In my opinion it can be reverted there was suggestion about reimplementing the goodies in smaller PRs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion it can be reverted there was suggestion about reimplementing the goodies in smaller PRs.
It cannot be done in smaller PRs, and a new PR will probably be larger in order to address the other issues.
I do have follow-up PRs to address the other issues but I am blocked right now as cppcheck wont build and I have PR to fix it which hasn't been merged: https://github.com/danmar/cppcheck/pull/8015(I think this is a must for any release)
I would prefer it not be reverted but if it has to be reverted, I would like all other cmake changes put on pause until it gets merged in with a priority that it will be merged in the next release as I dont want to have to maintain a fork of cppcheck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would prefer it not be reverted but if it has to be reverted, I would like all other cmake changes put on pause until it gets merged in with a priority that it will be merged in the next release as I dont want to have to maintain a fork of cppcheck.
that sounds reasonable to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to release Cppcheck 2.19 in couple of weeks.
Please suggest critical bugs that we need to focus on during the coming weeks.
daca crashes looks "acceptable" right now. There are two crashes with HEAD but we had those with 2.18 also.
http://cppcheck1.osuosl.org:8000/crash.html
here is a GUI test report (using a recent release-windows nightly build).
Version V 2.19
PASS 89
FAIL 17
NOT SURE 6
Total Test Cases 112
Last edit: Daniel Marjamäki 2025-11-04
is it ok to release this weekend? I feel there are no specific tickets we must solve.
We should probably fix this first: https://trac.cppcheck.net/ticket/14268 / https://github.com/danmar/simplecpp/issues/589
ok looks like firewave is on it already so we can wait a little..
Last edit: Daniel Marjamäki 2025-11-15
I am not sure if that will be fixed soon. I know what to change but there is some logic which needs to be tested and gives me headaches. I am fixing everything around it though.
Last edit: Oliver Stöneberg 2025-11-17
Since it seems there will be no fixes for the issues introduced by https://github.com/danmar/cppcheck/pull/7658 it needs to be reverted before release (I will post a PR if nothing happens until the end of the week).
We also need to land https://github.com/danmar/cppcheck/pull/7962 - I still want those changes to be cleaner though.
https://github.com/danmar/simplecpp/issues/583 also needs to be fixed (I am waiting for feedback on the initial work).
So does https://github.com/danmar/simplecpp/issues/556 so in turn https://github.com/danmar/simplecpp/pull/475 can finally land.
https://github.com/danmar/simplecpp/issues/570 is also important but I think we can go without that.
I guess we can revert it and then the changes can be polished and broken up and resubmitted.
It's still a draft PR. Do I understand correctly that compilation and linking works fine currently? But you want to utilize C++17 better? In that case I don't see this as that critical.
yeah.. have you been waiting for feedback from me? then I am sorry I missed it, please ping me again in the related PRs..
I agree this is very important I don't see any active PRs though :-(
Is it a regression?
I would like to release soon. Customers are waiting for some of the bug fixes. What more do you feel we need to fix before the release? Imho getting latest simplecpp fixes into cppcheck should be pretty high prio.
I can help out and I can ask ludvig, oleksandr and swasti to work on some tasks if there are suggestions..
Last edit: Daniel Marjamäki 2025-12-08
Sorry for the late reply. Here's an updated overview.
We need to add the suppressions in https://github.com/danmar/cppcheck/pull/8008 so it can be merged.
Still to be done for simple 1.6.4:
https://github.com/danmar/simplecpp/pull/599 (basically ready - still want to get it a closer look tomorrow)
regarding https://github.com/danmar/simplecpp/issues/556 / https://github.com/danmar/simplecpp/pull/475
I think it will be fine to release it without having the MinGW CI in-place and the known issues fixed. It only affects simplecpp since it is not hooked up in Cppcheck yet so the scope is also limited. Since the current CI does not fail and we already missed earlier issues it is obviously not a primary (or possibly even secondary) platform. It should definitely be fixed for the future 1.6.x/2.20 release (we should backport it for a patch release though). I am also pretty sure adapting the MinGW CI in Cppcheck will unearth more issues.
simplecpp 1.6.4 merge is already prepared in https://github.com/danmar/cppcheck/pull/8000
https://github.com/danmar/cppcheck/pull/7962 can also be applied after simplecpp 1.6.4 has been merged.
I still feel very strongly about reverting https://github.com/danmar/cppcheck/pull/7658 - see https://github.com/danmar/cppcheck/pull/8018. Let's keep any discussion in those tickets.
It is finally ready (CI still in progress though). Here's the PRs (in order):
https://github.com/danmar/simplecpp/pull/606
https://github.com/danmar/simplecpp/pull/599
https://github.com/danmar/cppcheck/pull/8000
https://github.com/danmar/cppcheck/pull/7962
No idea where we are at in terms of the CMake stuff.
I don't actually understand the details of the changes nor your objections. But I think your objections was ignored too quickly when you were not able to participate. There was a sense of urgency as there is a lot of flux and therefore hard to keep the PR up-to-date.
In my opinion it can be reverted there was suggestion about reimplementing the goodies in smaller PRs.
It cannot be done in smaller PRs, and a new PR will probably be larger in order to address the other issues.
I do have follow-up PRs to address the other issues but I am blocked right now as cppcheck wont build and I have PR to fix it which hasn't been merged: https://github.com/danmar/cppcheck/pull/8015(I think this is a must for any release)
I would prefer it not be reverted but if it has to be reverted, I would like all other cmake changes put on pause until it gets merged in with a priority that it will be merged in the next release as I dont want to have to maintain a fork of cppcheck.
that sounds reasonable to me.
Integrating simplecpp 1.6.4 (yet to be tagged) would fix the crash from https://trac.cppcheck.net/ticket/14268
I am releasing cppcheck-2.19.0
if there will be some more fixes that should be released we can release 2.19.1