Linting is broken

[szabolcsdombi]

The linting was working fine until now. I have cpptools Version 0.11.1: May 19, 2017

The 2 lines are contradictory. I get similar errors everywhere.

I am sure that the settings are correct. I had no linting problems before.

[ensky]

+1

[starsharp06sharp]

+1
After I upgrade my cpptools plugin to v0.11.1, I got tons of errors like this.

Add "C_Cpp.intelliSenseEngine": "Tag Parser" to settings.json can avoid this, but the IntelliSense will become "StupidSense"

[szabolcsdombi]

I just wiped my vscode install:

1. Deleted .vscode from My User Folder - you can loose your extensions
2. Deleted Code from %APPDATA% - you can loose your user settings
3. Added a clean c_cpp_properties.json to my project's .vsode folder.
4. Added a few "includePath" and "browse/path" that points to my MinGW install's include folder. - no headers from the Visual Studio install

Linting is back to normal

I cannot reproduce my original linting problem. I am not sure if point 1. and 2. are necessary to solve the problem.

[dtasev]

Did a clean install as well, did not work on Ubuntu 16.04

[bobbrow]

I am happy to help anyone having troubles getting linting to work. The reason you haven't had linting troubles in the past is because we didn't do any linting in the past besides a green squiggle for #includes we couldn't resolve.

For most people, updating your includePath in the c_cpp_properties.json file will fix your problems. The old IntelliSense engine did a recursive search for #includes, but the new engine does not.

In some cases, deleting your c_cpp_properties.json and letting the extension generate a new one might help, but only because we add additional includePaths that weren't previously added by the extension. You can experiment with this and then paste back in the other paths that you were using from your previous c_cpp_properties.json file.

And to address the original comment, the reason you see contradicting tooltips is because we are still in the process of implementing all of the editor features with the new IntelliSense engine. Goto definition results are still being populated by the tag parser. If this is distracting to you, you can disable the new IntelliSense engine for now by changing the intelliSenseEngine setting to "Tag Parser".

[starsharp06sharp]

Still doesn't work after I deleted my Code directory in ~/.config and .vscode directory in my workdir.
My c_cpp_properties.json is auto generated by my VSCode:

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [
                "${workspaceRoot}",
                "/usr/include",
                "/usr/local/include"
            ],
            "defines": [],
            "browse": {
                "path": [
                    "/usr/include",
                    "/usr/local/include"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            }
        },
        {
            "name": "Linux",
            "includePath": [
                "${workspaceRoot}",
                "/usr/include/c++/6",
                "/usr/local/include",
                "/usr/include"
            ],
            "defines": [],
            "browse": {
                "path": [
                    "/usr/include/c++/6",
                    "/usr/local/include",
                    "/usr/include"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            }
        },
        {
            "name": "Win32",
            "includePath": [
                "${workspaceRoot}",
                "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE"
            ],
            "browse": {
                "path": [
                    "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include/*"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            }
        }
    ]
}

Consider a cpp source code like this:

#include <iostream>

using namespace std;

int main()
{
    string str;
    cin >> str;
    cout << str;
    return 0;
}

and the IntelliSense doesn't work:

By the way, my OS is deepin 15.4(based on debian), my libstdc++ version is 6.2.0

[szabolcsdombi]

I mentioned that I did not add lines like:

"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"

I restored the the similar lines and I get linting errors again. Mine were:

"C:/Program Files (x86)/Windows Kits/10/Include/10.0.15063.0/um",
"C:/Program Files (x86)/Windows Kits/10/Include/10.0.15063.0/ucrt",
"C:/Program Files (x86)/Windows Kits/10/Include/10.0.15063.0/shared",
"C:/Program Files (x86)/Windows Kits/10/Include/10.0.15063.0/winrt",

[sean-mcmanus]

@starsharp06sharp For string you need #include <string>. However, I'm also reproing errors for cin. When I hover in iostream I see "Error: Failed to find translation unit".

[sean-mcmanus]

@starsharp06sharp Okay, I got the errors to go away after I added additional header files "/usr/include/x86_64-linux-gnu/c++/6.2.0" and "/usr/include/c++/v1". I'm not sure yet if we should be adding those as defaults or not. I think you need to find which headers you're using to compile and then then open the #include files to see if it needs more. The "Error: Failed to find translation unit" is a bug we need to investigate more (I've seen it many times somewhat randomly)...it's supposed to create a translation unit if none is found.

[bobbrow]

@sean-mcmanus the x86_64-linux-gnu path should be added if it is present, but v1 will not be added by default on Linux. @starsharp06sharp, can you respond back with the output of:

clang -v -E -x c++ - < /dev/null

That command should dump your default include path to the terminal.

[sean-mcmanus]

@bobbrow The x86_64-linux-gnu path isn't being added for me -- looks like a bug?

[bobbrow]

Yes, that would be a bug.

[roflhouse]

What is actually happening is that the recursive searching of includePaths entries is broken. It is only parsing directories that are specifically added. Which is a problem because most entries rely on the recursive searching of sub-folders.

[bobbrow]

It is not broken, but we're looking at ways to try to make the experience work better with less effort on your part.

Our fuzzy IntelliSense (tag parser) does recursive parsing of files, but I don't know of any compiler that does a recursive search of include paths. In order to provide semantic-aware features to the extension, the IntelliSense engine of necessity needs to act more like a compiler, and less like an approximation.

[starsharp06sharp]

thank you @bobbrow and @sean-mcmanus , after I add "/usr/include/x86_64-linux-gnu/c++/6", "/usr/include/x86_64-linux-gnu",, the IntelliSense works now

[starsharp06sharp]

The same question occured when I was openning c source code.

I have include the wchar.h and add its path to includePath and browse.path, but the lint still can't recognize wchar_t, should I define something?

This is my c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceRoot}",
                "/usr/include",
                "/usr/include/x86_64-linux-gnu"
            ],
            "defines": [],
            "browse": {
                "path": [
                    "/usr/include",
                    "/usr/include/x86_64-linux-gnu"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            }
        }
    ]
}

[ggreco]

NOTE: I had problem with intellisense on OSX since I upgraded to 0.11.1, the paths I had to add to my c_cpp_properties.json are:

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1",
"/usr/local/include",
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/8.1.0/include",
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include",
"/usr/include",
"/usr/include/c++/4.2.1"

Most of them can be retrieved with the command previously posted:

clang -v -E -x c++ - < /dev/null

But the last one (the bold one) cannot, I hope that this can help someone :)

[szabolcsdombi]

This is solved by now, closing the issue.