Thanks for your contribution.

Without actually looking at what it does - please add some unit and/or system tests for it.

I haven't looked into your implementation but I really like this. 👍

@firewave, any idea how to include certain .cpp files into the Visual Studio build? I don't have any experience with Windows development.

cppcheckexecutor.obj : error LNK2019: unresolved external symbol "public: __cdecl XMLAnalysisReport::XMLAnalysisReport(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0XMLAnalysisReport@@QEAA@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "protected: bool __cdecl CppCheckExecutor::parseFromArgs(class CppCheck *,int,char const * const * const)" (?parseFromArgs@CppCheckExecutor@@IEAA_NPEAVCppCheck@@HQEBQEBD@Z) [D:\a\cppcheck\cppcheck\test\testrunner.vcxproj]

Sorry for the late reply but I currently out sick. So still no code review...

@firewave, any idea how to include certain .cpp files into the Visual Studio build? I don't have any experience with Windows development.

cppcheckexecutor.obj : error LNK2019: unresolved external symbol "public: __cdecl XMLAnalysisReport::XMLAnalysisReport(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0XMLAnalysisReport@@QEAA@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "protected: bool __cdecl CppCheckExecutor::parseFromArgs(class CppCheck *,int,char const * const * const)" (?parseFromArgs@CppCheckExecutor@@IEAA_NPEAVCppCheck@@HQEBQEBD@Z) [D:\a\cppcheck\cppcheck\test\testrunner.vcxproj]

If #4652 is merged (could happen any day), dmake will take care of that. Until then you need to do it manually in the *.vcxproj files.

Since GitHub actions apparently support SARIF output could also also adjust the selfcheck workflow to use SARIF output instead of relying on the exitcode?

Also if SARIF is used should the exitcode be forced to 0? I have no idea how other tools implement this.

@firewave, unfortunately dmake does not create the Makefile target with the picojson include -isystem externals/picojson:

cli/sarifanalysisreport.o: cli/sarifanalysisreport.cpp cli/analysisreport.h cli/sarifanalysisreport.h externals/picojson/picojson.h lib/color.h lib/config.h lib/errorlogger.h lib/errortypes.h lib/suppressions.h
	$(CXX) ${INCLUDE_FOR_CLI} $(CPPFLAGS) $(CXXFLAGS) -c -o $@ cli/sarifanalysisreport.cpp

See https://github.com/mario-campos/cppcheck/actions/runs/3887481113/jobs/6633822871. Which means that, without tampering with the Makefile, dmake will generate a Makefile that fails to build cppcheck. Any suggestions?

I think this looks really interesting. There are some refactorings I would like to see.. but maybe instead of writing lots of nits it's quicker to just take over the finishing touches..

unfortunately dmake does not create the Makefile target with the picojson include -isystem externals/picojson:

I have the feeling that you can adjust dmake.cpp here:
https://github.com/danmar/cppcheck/blob/main/tools/dmake.cpp#L73

I guess it should say something like:

    else if (filename.compare(0, 4, "cli/") == 0) {
        getDeps("lib" + filename.substr(filename.find('/')), depfiles);
        for (const std::string & external : externalfolders)
            getDeps(external + filename.substr(filename.find('/')), depfiles);
    }

unfortunately dmake does not create the Makefile target with the picojson include -isystem externals/picojson:

I have made some fixes in this branch:

https://github.com/danmar/cppcheck/tree/4651

The fixes I made are here: https://github.com/danmar/cppcheck/commit/acca98d8f33e8f1f4bb5e06c4fb88277970830a2.diff
Feel free to apply those fixes locally. In particular I think the changes in dmake.cpp will help you.

There are still some tests that fail. You can run those tests with these commands:

 cd cppcheck/test/cli
 python3 -m pytest test-helloworld.py

If the tests are fixed I have the feeling that we can merge this PR.

I think this looks really interesting. There are some refactorings I would like to see.. but maybe instead of writing lots of nits it's quicker to just take over the finishing touches..

That would be helpful. Unfortunately, now that the holiday season is over, I don't have as much time for this PR as I did before. But, I will still continue to address the remaining problems as much as I can.

FYI there's already an PR which adds that output format command-line switch: #3365.