Code analysis: Add Cppcheck

[danmar]

Would it sound interesting to have Cppcheck support in cpptools? I see that clang-tidy is executed by cpptools and cppcheck can complement those results.

[sean-mcmanus]

@danmar It's being tracked by #669 .

[bobbrow]

Actually, that issue was closed because we don't currently have plans to do it.

[danmar]

Hi @sean-mcmanus ! Thanks for pointing out #669.

For your information I am the maintainer of the open source Cppcheck project.

There was a comment in #699 that a separate plugin for cppcheck should be created instead.

I would imagine that if we integrate cppcheck into cpptools then the existing configurations of include paths, defines, etc can be easily reused to run cppcheck also.

There are various cppcheck plugins and they always require separate configuration of include paths, defines, etc.

I am not an expert with the vscode plugin API. Would it be an alternative that cpptools exposed include paths, defines, etc so that other plugins could reuse this information? I imagine that cpptools can determine these settings dynamically by looking at cmake files etc.. and if so it's not good if all plugins have to reinvent this functionality..

Also I have heard that it's not possible to use the existing cppcheck plugins with remote sessions because they will try to run cppcheck locally. Does cpptools provide some functionality for remote sessions that would make it easier to run cppcheck remotely?

[sean-mcmanus]

@danmar As Bob mentioned, our team doesn't currently have the resources to integrate CppCheck. We implemented the clang-tidy support in cpptools via using the internal IntelliSense configuration as input, but it's possible that configuration info could be obtained via some other means such as the C/C++: Log Diagnostics command or reading a compile_commands.json, cpp_properties.json, or from a configuration provider via the vscode-cpptools-api (e.g. CMake Tools, Makefile Tools, etc.). So it might be possible to add that to our open source TypeScript or in another extension. Our extensions runs clang-tidy on the remote machine, since our entire extension runs on the remote machine in the VS Code remote scenario. I would think a cppcheck extension should be able to easily fix that by specifying the extension should run on the remote machine (I think there's some way to set that in the package.json). We do not implement any special remote handling -- that is just gotten for free from VS Code.

[bobbrow]

Issue #5038 tracks adding a command or updating the API to export the current source file configuration. I don't think that would be too much work for us, but it hasn't been prioritized yet.

[danmar]

our team doesn't currently have the resources to integrate CppCheck

I do understand that. If everybody wanted to have cppcheck and I would have free hands to design it exactly as I wanted then I could provide some resources..

I will investigate to make a separate plugin instead.

Issue #5038 tracks adding a command or updating the API to export the current source file configuration. I don't think that would be too much work for us, but it hasn't been prioritized yet.

Sounds great. That would be very interesting to me. We can look into how to fix that? If you would be open to solve it for a fixed price then let me know.

Our extensions runs clang-tidy on the remote machine, since our entire extension runs on the remote machine in the VS Code remote scenario. I would think a cppcheck extension should be able to easily fix that by specifying the extension should run on the remote machine (I think there's some way to set that in the package.json). We do not implement any special remote handling -- that is just gotten for free from VS Code.

that sounds great!