Vscode-cpptools: Code analyzer showing problems which are not there

[mkatliar]

After upgrade to v0.11.1 the VS code is showing lots of errors in both the PROBLEMS window and the source windows. The code compiles fine and the errors seem to be caused by the analyzer not seeing the include paths.

[sean-mcmanus]

You need to do a C/Cpp: Edit Configurations to generate a c_cpp_properties.json and then fill in the includePath and defines settings to match whatever you have set in your CMakeLists.txt for the source files you're interested in. The path is not recursive. You may also want to set the browse.path (it's recursive and intended for source files as well). In the future, we want to automatically figure this out, like Visual Studio 2017 does. If that's too much trouble and you don't want errorSquiggles, you can change the setting to Disabled. See https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/FAQ.md

[assemblyDruid]

Hi @mkotlyar and @sean-mcmanus. I'm having the same issue. I was able to figure out that the paths needed to be included in c_cpp_properties.json, and have done so for both the include paths and the browse paths and I am still seeing many non-existent errors. The strange thing is, I was not seeing any of this behavior before I upgraded to the latest C/Cpp release/patch.

[sean-mcmanus]

@cfarvin You weren't seeing these error previously, because the last update changed the default settings to Default for IntelliSenseEngine...or are you saying you had errorSquiggles enabled before the last update? What do you mean by non-existent errors? Does it say "cannot open source file"? If a variable doesn't exist, can you open the #include files until you find one that gives error squiggles? There is a known issue in which the default includePath isn't auto-populated with a path that has a variation of x86_64-linux-gnu.

[assemblyDruid]

@sean-mcmanus I did not see squiggly lines before the update, apologies if that was unclear. By non-existent errors, I was referring to the title of this post "problems which are not there". I am indeed on GNU/linux x64, this may be the issue. I am able to peek into the #include files, even with squiggly marks. I am tinkering with the c_cpp_properties.json to see if this can be fixed.

[sean-mcmanus]

@cfarvin Yeah, if you can peek to the correct definition, then it means the "Tag Parser" is able to recursively find the header file from the browse.path, but the includePath needs additional paths due to its non-recursiveness. If you create a new c_cpp_properties.json, we're supposed to populate it with defaults for system headers, but in some cases we're missing the GNU ones due to some bug we're investigating.

[assemblyDruid]

@sean-mcmanus Interestingly, after performing [ctrl+shift+p] > C/Cpp: Select a Configuration > Linux, I haven't seen any issues. I thought that before the configuration was being detected automatically, but I may have been mistaken (or, the configuration was not detected). @mkotlyar, maybe this will solve the problem for you as well?

[sean-mcmanus]

@cfarvin Yes, if you're on Linux, it's supposed to default to the Linux config...unless you add > 3, then it'll use the last one.

[assemblyDruid]

So today I'm experiencing this same issue anew. I tried re-selecting my platform as I mentioned above ^, and all of my libraries/headers/dependencies are correctly given paths in the c_cpp_properties.json. The issue seems to be primarily with the openGL functions, though I have included the correct directory and listed the contents of that directory for you in the terminal (see screenshot 2).

Keeping Sean's last comment in mind, I only have the three default platforms defined in the properties json.

[sean-mcmanus]

@cfarvin I would remove the / at the end of the includePath. The recommended way to track down errorSquiggle problems is to try to locate the first "cannot find include path" that occurs in a translation unit (using Peek Definition can help if the required include can be found recursively from the browse.path includes). It likely that one of the #include files requires an additional include path. We plan to do the include path searching ourselves later so the child include errors are made visible automatically. Or you can set errorSquiggles to Disabled until we improve the experience.

[assemblyDruid]

@sean-mcmanus Thanks for the advice. I did try that, but no cigar. I'll disable it for now and look forward to the next release.

Alternatively... is there a way that I can get involved to help? I believe this project is open source, though I have not had the pleasure of contributing to a project before.

[sean-mcmanus]

@cfarvin The next 0.11.3 update probably won't resolve your issue, but 0.11.4 might. Our extension is not open source, but the C/C++ syntax highlighter is open source at https://github.com/atom/language-c/issues if you see any bugs you're interested in fixing there (I remember seeing a bunch of issues, and we don't have the bandwidth to fix them). You could also help test and get repros for bugs and review the javascript code for issues in the extension's out\src folder. And you could also contribute to VS Code itself -- we've filed multiple bugs with VS Code (https://github.com/Microsoft/vscode/issues ) for features we want for the C/C++ scenario, such as a way to get C/C++ compiler and linter errors to be shown chronologically instead of grouped by files.

[spinicist]

Hi - I was having similar problems with lots of squiggles. I have resorted to going back to the Tag Parser for the time being. I use the ITK library (https://github.com/InsightSoftwareConsortium/ITK), which has an ungodly number of include paths. Adding them all individually to includePath isn't feasible, so I need a recursive parser.

Unless there's some way to tie in with the excellent CMake extensions from @twxs and @vector-of-bool to get the include paths out of CMake?

Thanks for the hard-work on the C/C++ extension! VS Code is a very pleasant editor for projects at the scale I work on.

[sean-mcmanus]

@spinicist Have you tried the CMake Tools Helper extension by maddouri? It claims to bridge the gap between the C/C++ and CMake Tools extension by doing exactly what you're asking for. https://marketplace.visualstudio.com/items?itemName=maddouri.cmake-tools-helper

[spinicist]

@sean-mcmanus No, I haven't. Will have to try it. I've been so impressed by @vector-of-bool's extension that I hadn't looked for any others. Thanks!

EDIT: It's known to not handle the all target, which is what I most often use. Even selecting another target still results in a null configuration, so doesn't work for me right now. Oh well, was worth a try.

[vector-of-bool]

@sean-mcmanus, @spinicist, I have an extension API that exposes compilation options on a file-by-file basis using CMake Server. Is there any possibility for integration with that API rather than solely relying on the c_cpp_properties.json?

[michelleangela]

Closing this issue due to long inactivity.