fix #13993: simplecpp: bump to 1.4.4 by ludviggunne · Pull Request #7650 · cppcheck-opensource/cppcheck

ludviggunne · 2025-07-07T09:27:12Z

No description provided.

firewave · 2025-07-07T09:34:40Z

@@ -1,11 +1,77 @@
-file(GLOB hdrs "*.h")


Only the sources need to be updated.

It might make sense to add a small script to the tools folder which pulls the latest simplecpp source and copies it over into the folder.

Is a bash script fine for that or should it be cross platform?

ludviggunne · 2025-07-07T10:56:48Z

There are some failures now due to undefined QT macros, I'm not quite sure how to deal with these. Add them to cfg/qt.cfg? Or define on the command line?

firewave · 2025-07-07T11:04:09Z

There are some failures now due to undefined QT macros, I'm not quite sure how to deal with these. Add them to cfg/qt.cfg? Or define on the command line?

Add the library if it it is missing in the context (either via Settings or --library). If the library is already provided we need to add it to the configurations as the user will encounter the same issue.

Since those are version check macros it would be great if we implement those so the configuration detection could come up with something that would check both cases but that is out of scope. @chrchr-github

ludviggunne · 2025-07-07T12:00:00Z

I've updated some cfg-files.
The qt macro is from here: https://doc.qt.io/qt-6/qtversionchecks-qtcore-proxy.html#QT_VERSION_CHECK
The wxwidgets macro is from here: https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/version.h

firewave · 2025-07-07T16:29:01Z

In XML you need to encode & as & in strings.

danmar · 2025-07-09T09:55:13Z

  <define name="QT_FORWARD_DECLARE_CLASS(name)" value="class name;"/>
  <define name="QT_FORWARD_DECLARE_STRUCT(name)" value="struct name;"/>
+  <define name="QT_VERSION_CHECK(major, minor, patch)" value="((((major) &amp; 0xff) &lt;&lt; 16) | (((minor) &amp; 0xff) &lt;&lt; 8) | ((patch) &amp; 0xff))"/>
+  <define name="QT_CONFIG(feature)" value="(1/QT_FEATURE_##feature == 1)"/>


I am not sure about this.. if the QT_FEATURE is not defined then there will be a unclear preprocessorErrorDirective warning it seems? I fear that it will force our users to configure a whole bunch of QT_FEATURE macros.. how about (QT_FEATURE_##feature == 1) instead?

It feels like this is out of scope for this PR but;

I think it can be unfortunate to copy paste macros as is from library headers if it will create stronger dependency on library internals.. that will more or less remove the benefit of the library and the headers could have been included directly instead to get the real macros instead..

The idea with having a division by zero is that it will generate a compile error if the macro isn't defined. But I suppose that's not something cppcheck needs to do. So just checking ==1 might be better.

I'm don't know the qt build system very well, but if the feature macros will be added in a compilation database, that should be fine. But then I guess I shouldn't have had to add those manually in the CI... I can try to reproduce and create a ticket.

I think it can be unfortunate to copy paste macros as is from library headers if it will create stronger dependency on library internals.. that will more or less remove the benefit of the library and the headers could have been included directly instead to get the real macros instead..

copy and pasting from licensed headers has other implications. but let's not discuss that right now.

There is a way to getting the actual macro values pointed out here: https://trac.cppcheck.net/ticket/8956#comment:10. But that seems to be the approach for the internal defines. I did not find the ticket about source defined ones.

Actually that is the way to do it:

$ gcc -E -dM $(pkg-config --cflags-only-I Qt6Core) a.cpp | grep QT_CONFIG #define QT_CONFIG(feature) (1/QT_FEATURE_ ##feature == 1)

danmar · 2025-07-09T09:59:13Z

        if: false # TODO: fails with preprocessorErrorDirective - see #10667
        run: |
-          ./cppcheck -q --template=selfcheck --error-exitcode=1 --library=cppcheck-lib --library=qt -D__CPPCHECK__ -D__GNUC__ -DQT_VERSION=0x060000 -DQ_MOC_OUTPUT_REVISION=69 -DQT_CHARTS_LIB -DQT_MOC_HAS_STRINGDATA --enable=unusedFunction --exception-handling -rp=. --project=cmake.output/compile_commands.json --suppressions-list=.selfcheck_unused_suppressions --inline-suppr
+          ./cppcheck -q --template=selfcheck --error-exitcode=1 --library=cppcheck-lib --library=qt -D__CPPCHECK__ -D__GNUC__ -DQT_VERSION=0x060000 -DQ_MOC_OUTPUT_REVISION=69 -DQT_CHARTS_LIB -DQT_MOC_HAS_STRINGDATA --enable=unusedFunction --exception-handling -rp=. --project=cmake.output/compile_commands.json --suppressions-list=.selfcheck_unused_suppressions --inline-suppr -DQT_FEATURE_shortcut -DQT_FEATURE_tooltip


hmm.. it's probably out of scope for this PR but I think the messy qt macros are unfortunate. For instance Q_MOC_OUTPUT_REVISION is not used directly in our code and shouldn't have to be defined manually. The QT_FEATURE_ macros should not have to be defined manually..

That define is used by the generated code. And we need to define them manually because we do not use a project as input. But we already discussed that in another ticket.

ludviggunne · 2025-07-09T16:50:18Z

Should we just leave the library configurations untouched for this PR, and supply the macros on the command line in the CI for now? I feel like any other approach (such as the one where we parse the gcc output) is maybe a bit out of scope right now. Then again, now that simplecpp produces errors for undefined funcitonal macros, it might affect users who would also need to define these manually. @danmar @firewave

firewave · 2025-07-10T11:01:54Z

They need to be added to the libraries because if we encounter this then users will also encounter it - and they will probably encounter even more than we do.

It is also a bit unfortunate that we now have two different behaviors for unknown macros albeit in different contexts. Maybe those missing preprocessor macros should be reported via a separate error ID im simplecpp and be treated as #if 0. That way it would not bail out and we could forward those to the unknownMacro errors in Cppcheck. That way they would also show up in the proper reports in daca.

ludviggunne · 2025-07-11T10:46:38Z

There is now a different release that omits 4bbd1bf8e320471f2a46908c947251ed8aa18b0e.
https://github.com/danmar/simplecpp/releases/tag/1.4.3.1
I will make a new PR for integrating these changes in order to make it possible to deal with __has_include correctly in cppcheck.

ludviggunne · 2025-10-07T13:43:55Z

A later version has already been merged
12e63b4

firewave reviewed Jul 7, 2025

View reviewed changes

firewave marked this pull request as draft July 7, 2025 09:35

ludviggunne force-pushed the 13993 branch from bd68d3c to 1054fda Compare July 7, 2025 09:41

ludviggunne force-pushed the 13993 branch from f89417d to bf59106 Compare July 7, 2025 11:58

ludviggunne force-pushed the 13993 branch from bf59106 to 25ed72d Compare July 7, 2025 12:54

ludviggunne force-pushed the 13993 branch 3 times, most recently from 390e372 to aa3ea43 Compare July 9, 2025 10:07

danmar reviewed Jul 9, 2025

View reviewed changes

ludviggunne force-pushed the 13993 branch 2 times, most recently from be25de4 to 5a60f72 Compare July 9, 2025 10:35

ludviggunne added 5 commits July 10, 2025 17:44

fix #13993: simplecpp: bump to 1.4.4

6945b1a

add some functional macros to qt.cfg

1497f5f

add wxCHECK_VERSION(...) to wxwidgets.cfg

2222a30

update inline suppression test

ce8ab21

update workflows

054f4ad

ludviggunne force-pushed the 13993 branch from 5a60f72 to 054f4ad Compare July 10, 2025 15:44

ludviggunne closed this Oct 7, 2025

Conversation

ludviggunne commented Jul 7, 2025

Uh oh!

firewave Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ludviggunne commented Jul 7, 2025

Uh oh!

firewave commented Jul 7, 2025

Uh oh!

ludviggunne commented Jul 7, 2025

Uh oh!

firewave commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ludviggunne commented Jul 9, 2025

Uh oh!

firewave commented Jul 10, 2025

Uh oh!

ludviggunne commented Jul 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ludviggunne commented Oct 7, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

firewave Jul 7, 2025 •

edited

Loading

firewave commented Jul 7, 2025 •

edited

Loading

ludviggunne commented Jul 11, 2025 •

edited

Loading