detect Cppcheck integration issues earlier

[firewave]

The last simplecpp bump had to revert two PRs because they did not work with Cppcheck. We need to find a way to detect these issues before integration them downstream.

See https://trac.cppcheck.net/ticket/13635 for downstream issue.

[firewave]

Ideas:

• add scheduled jobs with latest simplecpp source to Cppcheck CI
  The downside would be there it is disjointed from the PR and we would have to manually check. The feedback would also be delyed and if many things were merged we would not know what caused the issue.

• adjust Cppcheck workflows to be triggerable and have an option to use a certain simplecpp version
  This would give us feedback within the PR context. It would delay the CI run of the PR though. We could make it not wait on the result and just add a comment to the upstream PR. We could also limit this to after it was merged - doing a fix-up afterwards would be fine IMO. That would mainly preserve the autonomy from Cppcheck.

[Tal500]

Ideas:

* add scheduled jobs with latest simplecpp source to Cppcheck CI
  The downside would be there it is disjointed from the PR and we would have to manually check. The feedback would also be delyed and if many things were merged we would not know what caused the issue.

* adjust Cppcheck workflows to be triggerable and have an option to use a certain simplecpp version
  This would give us feedback within the PR context. It would delay the CI run of the PR though. We could make it not wait on the result and just add a comment to the upstream PR. We could also limit this to after it was merged - doing a fix-up afterwards would be fine IMO. That would mainly preserve the autonomy from Cppcheck.

A simple start - add a cppcheck workflow step that clone the upstream cppcheck repo, build it with the local simplecpp version, and run make test

[danmar]

I don't have a strong opinion about the ideas.. but imho the scheduled work option will not work because as you say "disjointed from the PR and we would have to manually check"

[firewave]

Yes. I just wrote them down as I was thinking about it and during that it became obvious the second case is the only way to go.

[firewave]

Since any change will ultimately lead to a downstream PR at some point, we could create a downstream schedule which automatically generates/updates a PR when changes are detected. That would be how danmar/cppcheck#7659 might come into play. It would still be disjoint but eliminate some manual steps.