In D17432#373407, @cullmann wrote:

Ähm :P closeSplitView is an API function exposed via the KTextEditor::MainWindow.
cppcheck can't see that, as called via invoke.

Does this explain why this issue is not reported by Cppcheck when the header files are not passed directly (when the first variant of Cppcheck is used)?

For the other thing: I have no issues with the second checker, but could the name be something better than "2"? :=)

Yes, I will rename it.

No idea ;=)
A static checker should not be able to detect that this method is unused (beside if it assumes its non-exported and it sees no calls in the complete program, but cppcheck normally doesn't analyze whole-program things).

Hmm. Now, I am in doubt if calling Cppcheck on header files directly is such a good idea after all.

;=)

If cppcheck works at least a bit like other checkers (like the one I work on, too: https://www.absint.com/rulechecker/ ), it should work on header files, too, and not only on compilation units.

The question is, how conservative some checks are, e.g. this "unused" seems a bit adventurous to assume a public method is unused.

Wouldn't it be better to make it possible to configure the current CppCheck in stead of adding a new one?

At work I have a QML application with a bunch of models that expose functions to QML, but cppcheck does not know about that and warns about unused functions. I figure there could be more situations that the current cppcheck parameters are not optimal for...

I can imagine to have a second combobox which is defined per tool. It would contain commonly used options.
For the "Cppcheck (C++ only)" mode, the option would have to define arguments to the tool and make changes to the default file filter.

@Kåre, for your QML use case, could you define options in a similar way or what kind of flexibility would you need?

I dislike the fact that we have two times almost the same thing. Then again I can see that if C++ is set explicitly, the cppcheck plugin will be unusable for C. Then again, cppcheck contains 'cpp' in its name. So should we care about C at all here? If the answer is 'no', I would prefer to simply add the command line option and be done with it :-) or add an option in the Projects config page.

PS: i wrote this yesterday but forgot to click submit :p

In D17432#373749, @dhaumann wrote:

I dislike the fact that we have two times almost the same thing. Then again I can see that if C++ is set explicitly, the cppcheck plugin will be unusable for C. Then again, cppcheck contains 'cpp' in its name. So should we care about C at all here? If the answer is 'no', I would prefer to simply add the command line option and be done with it :-) or add an option in the Projects config page.

I like the idea:

1. Restrict the original "Cppcheck (C++)" to C++ and remove the ".c" file extension from the list (and still do not search header files since these seem to generate false positives)
2. Add another version "Cppcheck (C)" which is set to "c" and then only search within .c files.

Hmm, actually, would it not be just nicer to enhance the one cppcheck analysis class to feed the different language files with the correct parameters to cppcheck?
That way, we just can have one analyzer object dealing with cppcheck.

Makes sense.