Vscode-cpptools: IntelliSense doesn't recognize standard types, e.g. size_t, uint64_t

[hensz]

Hi!

With the latest update of this extension IntelliSense works much better - if you setup the include paths correct. However in my case it has problems recognizing standard types like size_t or uint64_t.

I'm using gcc on SLES12 Linux, so those types are defined in /usr/include/c++/6/x86-64-suse-linux/bits/c++config.h which is included by #include (which is located in /usr/include/c++/6/) in my source file. I also added both /usr/include/c++/6/ and /usr/include/c++/6/x86_64-suse-linux/ as include path.

What's also not that helpful is that the Problems view (and the error squiggles) only mention "size_t is not a type name" - but not why. There's no trace of a missing include of unknown define.

This is the list of my include paths in c_cpp_properties.json:
...
"name": "Linux",
"includePath": [
"/usr/include",
"/usr/include/linux",
"/usr/include/c++/6",
"/usr/include/c++/6/tr1",
"/usr/include/c++/6/x86_64-suse-linux/",
"/usr/lib64/gcc/x86_64-suse-linux/6/include/"
],
...

Thanks in advance for any help!
Torsten

[bobbrow]

Does your include path match what your compiler reports? e.g. gcc -v -E -x c++ - < /dev/null
If it does, then the issue would be with the "defines". I'm downloading the SLES 12 iso right now so I can check, but if you get to this before I do, please let me know.

[hensz]

Hi!
I just checked the output of the command you wrote. There were a few include paths output that I hadn't added to c_cpp_properties.json:
"/usr/include/c++/6/backward",
"/usr/local/include",
"/usr/lib64/gcc/x86_64-suse-linux/6/include-fixed",
But when I added those this didn't change anything regarding my issue.

[rdlaner]

I'm having the same issue using GCC on Windows...

[bobbrow]

@rdlaner, if you are using MinGW, check here. If not, please let us know where you got GCC from as well as where your headers live in the filesystem.

[rdlaner]

I'm using the GCC included in the Xilinx SDK I'm using on a project. These are all of the include paths I am using for the gcc compiler, I include them in both the "includePath" and "browse" arrays in the c_cpp_properties.json file:
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/lib/gcc",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/lib/gcc/arm-none-eabi",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/5.2.1",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/5.2.1/include",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/5.2.1/include-fixed",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/include",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/include/c++/5.2.1",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/include/c++/5.2.1/arm-none-eabi",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/include/c++/5.2.1/backward",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/include/c++/5.2.1/tr1",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/include/c++/5.2.1/tr2",
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/arm-none-eabi/libc/usr/include"

The stdint header file exists at this location, which is one of the above include paths:
"C:/Xilinx/SDK/2016.3/gnu/aarch32/nt/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/5.2.1/include"

The IntelliSense places a red squiggle under every uint32_t, etc. However, if attempt to go to definition for each type, VS Code opens the correct stdint header. I have tried including the exact stdint header file in the "includePath", but it still does not resolve the red squiggles.

[bobbrow]

Do you have "intelliSenseMode" set to "clang-x64"? The default on Windows is "msvc-x64" and it doesn't work well with GCC includes.

When you open the stdint header, do you get a tooltip when you hover over uint32_t? If not, then it is in an inactive preprocessor block and we'll need to find out what it is so that we can add the appropriate symbol to add to the "defines" array in your c_cpp_properties.json file.

Does Xilinx have a free or trial version I can download? I didn't see one on their website.

[rdlaner]

Ah, I found the issue. The Xilinx SDK has multiple stdint.h headers and two were included in my include path. I found that if I include the path to the one I want to use, it will use that one first.

Is there a good way to exclude specific files or even directories in the c_cpp_properties.json file?

[bobbrow]

There is no way to exclude specific files or directories. We basically just pass this list down to the front end compiler.

You should try to emulate whatever gcc -v -E -x c++ - tells you the path to your system includes is.

[bobbrow]

@hensz, I tried SLES 12, but could only get an evaluation version with updates disabled. Since I'm not so savvy with this distro, I didn't figure out how to get the matching gcc on it properly because yast didn't want to cooperate with me.

But I tried openSuse Leap and installed gcc 6 on it. Everything works fine for me when I update the includePath. This is what I have:

            "includePath": [
                "/usr/include/c++/6",
                "/usr/include/c++/6/x86_64-suse-linux",
                "/usr/include/c++/6/backward",
                "/usr/lib64/gcc/x86_64-suse-linux/6/include",
                "/usr/local/include",
                "/usr/lib64/gcc/x86_64-suse-linux/6/include-fixed",
                "/usr/x86_64-suse-linux/include",
                "/usr/include",
                "${workspaceRoot}"
            ],

Can you share the final include path that you settled on?

[hensz]

Hi!
This is my current includePath:

```json
"includePath": [
"/usr/include",
"/usr/include/linux",
"/usr/include/c++/6",
"/usr/include/c++/6/tr1",
"/usr/include/c++/6/x86_64-suse-linux/",
"/usr/lib64/gcc/x86_64-suse-linux/6/include/",
"/usr/include/c++/6/backward",
"/usr/local/include",
"/usr/lib64/gcc/x86_64-suse-linux/6/include-fixed",
"${workspaceRoot}"
],
````

Is there any way to get some diagnose information about how the extension tries to resolve the type? Perhaps I have some potentially "matching" includes that contain strange preprocessor stuff which causes the extension to fail.

[bobbrow]

Unfortunately, there is no diagnostic information about this. Includes are simply resolved from top to bottom, so order matters. /usr/include should most likely not be at the top of the list. Did you try copying the includePath that I shared? If mine doesn't work for you, you should copy whatever gcc-6 -v -E -x c++ - < /dev/null prints out.

[hensz]

Hi!
I tried the includePath settings you shared, and with these (and some more defines) it seems to work now.
Thanks a lot!

[aakre]

I'm experiencing a similar problem. All fixed size integer types (uint8_t, uint16_t, uint32_t etc...) are marked as undefined by intellisense.

My setup:

• vscode 1.19.2
• c/c++ extension 0.14.6
• Ubuntu 16.04 LTS
• arm toolchain version 7.2.1.

I have set my includePath and browsePath according to the output of
arm-none-eabi-gcc -Wp,-v -E -xc -x c++ /dev/null:

"includePath": [
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/arm-none-eabi",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/backward",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include",
                "${workspaceRoot}",
            ]

I've also tried to use the compile_commands.json-file generated by cmake, but that did not change anything. My project builds and runs fine.

I'm hoping someone can shed some light on this issue again :)

[sean-mcmanus]

@aakre I think you're missing a compiler defines, such as __GNUC__=7. We have a known issue in which the compiler defines aren't set automatically (as the includePath sometimes is). A related issue was https://github.com/Microsoft/vscode-cpptools/issues/1293 .

[aakre]

@sean-mcmanus Thanks for getting back to me on this. I tried adding GNUC, __GNUC__, __GNUC__=7 and even __GNUC_MINOR__=2 and __GNUC_PATCHLEVEL__=1 in several combinations but my integers are still undefined.

So I tried to construct a minimal example with this issue to investigate further (apologies for the long post)
My source code:

#include <stdint.h>

int main()
{
    uint8_t x = 8;
    uint16_t y = 16;
    uint32_t z = 32;

    return 0;
}

With default includePath and browsePath, I get no errors and if I hover the types I get:

typedef unsigned char uint8_t
typedef unsigned short uint16_t
typedef unsigned int uint32_t

which are defined in /usr/lib/gcc/x86_64-linux-gnu/5/include/stdint-gcc.h.

Then I replace the default paths with my toolchain headers:

"includePath": [
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/arm-none-eabi",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/backward",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed",
                "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include",
                "${workspaceRoot}",
            ]

"browse": {
                "path": [
                    "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1",
                    "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/arm-none-eabi",
                    "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/backward",
                    "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include",
                    "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/include-fixed",
                    "/usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include",
                    "${workspaceRoot}"
                ]

Then uint8_t and uint16_t gets a red squiggle and is marked as undefined. uint32_t is fine and if I hover I get: typedef __uint32_t uint32_t.
Hitting F12 leads me to /usr/lib/gcc/arm-none-eabi/7.2.1/include/stdint-gcc.h.

Now here is the strange part:
When I define "__GNUC__" it _sometimes_ work. I say sometimes, because I cannot reproduce this accurately. I've tried to create a blank project with the steps mentioned above a couple of times, and _sometimes_ intellisense identifies uint8_t as __UINT8_TYPE__ and uint16_t as __UINT16_TYPE__.
However, the times it worked it only worked once, because when I closed vscode and reloaded the project, I was left with red squiggles.

This is so strange that there must be something wrong somewhere else I guess, but I have absolutely no idea what.

[sean-mcmanus]

@aakre Does the ordering of your includePaths match your compiler's defaults? We can't think of anything that could cause IntelliSense to give different results "sometimes" (other than issues with squiggles randomly not updating correctly after edits or edits to #included headers). We could try to install the arm-none-eabi/7.2.1 to see if we can repro the issue.

[aakre]

@sean-mcmanus The ordering match the output of the command:
arm-none-eabi-gcc -Wp,-v -E -xc -x c++ /dev/null if that is what you mean.

If you guys have the time and resources to investigate this, then that would be great! My setup is described in a previous post in this thread.

[sean-mcmanus]

@aakre I moved this to https://github.com/Microsoft/vscode-cpptools/issues/1484 -- it's too hard to track as part of a closed issue.