johnthagen
Cppcheck should only be invoked with a single configuration
Environment
- Operating System (e.g. Ubuntu 16.04 x64): Windows 10
- IDE Version (e.g. CLion 2016.3.2): Clion 2020.1 (201.6668.86)
- Cppcheck executable version (
cppcheck --version): 1.90 - Cppcheck plugin version: 1.4.2
Expected behaviour
The inspections show issues in active code only.
Actual behaviour
The inspection may should code in non-active (i.e. _MSC_VER although GCC is being used) blocks.
If Cppcheck is invoked with just a source file it tries to detect and process all configuration (i.e. defines) in the source. In case of the IDE it should only do a scan for that current configuration. This requires the plugin to get this from the IDE (if possible) and provide it to the call.
A workaround is using --max-configs=1 in the command-line parameters. This will greatly improve the scan times for files with a lot of detected configuration.
If there's too many configuration Cppcheck will bail out and only check at most what is configured via --max-configs (default is 12) anyways:
Too many #ifdef configurations - cppcheck only checks 12 of 17 configurations. Use --force to check all configurations.
The checking of the file will be interrupted because there are too many #ifdef configurations. Checking of all #ifdef configurations can be forced by --force command line option or from GUI preferences. However that may increase the checking time.
So I think for the time being we should always invoke it with either --max-configs=1 or --force for consistency.
I contacted JetBrains about this and got a contact regarding CLion plugin development. Hopefully I will get some input on this soon.
To get the project configurations it is necessary to use CLion-specific functionality. I haven't figured out yet how to develop with them. There also were some recent changes outlined in https://blog.jetbrains.com/clion/2020/12/migration-guide-for-plugins-2020-3/
This probably makes the plugin CLion/AppCode-only but to be honest without the proper data for the file Cppcheck will never give you all the actual results.
If we have access to the build path (I know we can access the workspace path) we could leverage a potentially existing compile_commands.json to get the configuration. Maybe this could be done by leveraging the internal macros mentioned in #40.