danmar
refs #10692 - added command-line option `--cpp-header-probe` to probe headers and extension-less files for Emacs C++ marker
Still work in progress...
The standard library and LLVM are specifying this among others. Just running it on /usr/include will encounter lots of actual usages.
This will be disabled by default but I am considering enabling it by default in the release afterwards.
Will also add a commit which adds it to our headers. Will most likely do it in a separate PR.
Requires #6325 to be merged first.
After #6211 has landed (if even possible) and we finally upgraded to PCRE2 (see https://trac.cppcheck.net/ticket/10610) we should replace most of the messy parsing code with a regular expression.
What is the canonical use case for this?
That is described in the ticket. It is mainly for IDE integrations. When you open a header by default it will be treated as C file and when it is actually C++ code it will error out. So you need to specify --language=c++ so the analysis is performed. But that would also force (and override the existing Path::identify() calls) all source files to be treated as C++ even though they might be C code.
For the CLI usage this should not have any impact at all since the probing would only be performed if you explicitly pass a file with the *.h or no extension (like the C++ standard headers). I probably should change the command-line option to --cpp-header-probe (or similar) indicate that.
This is based on the implementation of the CLion plugin which only has a single global configuration for the options being provided.
On a side note it already helped to detect two issues hard to spot issues. 😀
What is the canonical use case for this?
That is described in the ticket. [...]
Thanks for the explanation. IDEs were mentioned in the ticket, but I didn't make the connection to IDE integration.
Thanks for the explanation. IDEs were mentioned in the ticket, but I didn't make the connection to IDE integration.
I just realized there is no upstream ticket for this. It is mentioned in the known issues though: https://github.com/johnthagen/clion-cppcheck?tab=readme-ov-file#analyzing-header-files.
I also encountered some performance issues with some headers even when I disable ValueFlow and all checks so it is probably related to the tokenizing or preprocessing. I have not looked into that yet.
I also encountered some performance issues with some headers even when I disable ValueFlow and all checks so it is probably related to the tokenizing or preprocessing. I have not looked into that yet.
Turns out this only occurs in a debug build so there is no issue.
To test this with existing headers I patched out some code for speed, enabled the logging in hasEmacsCppMarker() and ran find /usr/include -type f | xargs -n 1 bin/cppcheck -D__GNUC__ --cpp-header-probe -q 2> /dev/null (FYI that found 2812 markers).
It seems this uncovered bad markers in the LLVM headers which I reported upstream: https://github.com/llvm/llvm-project/issues/89965.
This does not currently handle markers in /* */ comments. I will add support for that in a follow-up PR.