Vscode-cpptools: uint8_t undefined with arm-none-eabi toolset

[sean-mcmanus]

Moved from issue https://github.com/Microsoft/vscode-cpptools/issues/916#issuecomment-359398467 by @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 I got the arm-none-eabi and I'm able to repro the bug as described.

[sean-mcmanus]

@aakre With the headers you're using __UINT8_TYPE__ and __INT8_TYPE__ are not defined. Adding those to the defines fixes the issue for me ( "defines": ["__UINT8_TYPE__=unsigned char", "__INT8_TYPE__=char"],). You should find out where your compiler is getting those definitions from (I assume arm-none-eabi-gcc -Wp,-v -E -xc -x c++ /dev/null would show this). We have an issue on our backlog to make sure the compiler defines are used by default. Are you able to get it working via adding those defines?

[aakre]

@sean-mcmanus Thank you for excellent support!

Defining the types manually as you suggest fixes the issue. At least in my case I also have to exclude compile_commands.json for this to work. Thanks again :)

[sean-mcmanus]

-dD can be used to see the internal defines used by arm-none-eabi-gcc -- we're planning to automatically set those defines and an option to set the compiler, so then compile_commands.json will be usable too.

[dariuszseweryn]

I am having probably the same issue. After setting up the includePath the IDE does not know what to do with uint8_t.

I have also tried to add "defines": ["__UINT8_TYPE__=unsigned char", "__INT8_TYPE__=char"] but unfortunately it did not helped.

I would also want to add that having an auto IntelliSense setup from the compile_commands.json file would be awesome! <3 Looking forward to it.

[SUlbrichA]

I have the same issue as @dariuszseweryn. Despite the "defines" in c_cpp_properties.json, uint8_t and alike are unkown

[sean-mcmanus]

@SUlbrichA Can you try our Insiders build at https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.15.0-insiders and then look for code that is grayed out that should not be in or before the file that is supposed to define the uint8_t type? The grayed out code would indicate that defines are missing. Otherwise, I think we need more repro info, such as the compiler version used. We've had reports of issues with gcc 7.2.

[SUlbrichA]

@sean-mcmanus I installed the insiders build and if I place an #ifndef block for __UINT8_TYPE__ in my main.c file, its content is grayed out as expected and the tool tip shows the correct definition (good job btw.)
In stdint-gcc.h where uint8_t is defined however, the same does not work somehow.

Excert from my c_cpp_properties.json
json "/usr/arm-none-eabi/include/c++/7.2.1", "/usr/arm-none-eabi/include/c++/7.2.1/arm-none-eabi", "/usr/arm-none-eabi/include/c++/7.2.1/backward", "/usr/lib/gcc/arm-none-eabi/7.2.1/include", "/usr/lib/gcc/arm-none-eabi/7.2.1/include-fixed", "/usr/arm-none-eabi/include" ], "defines": [ "__UINT8_TYPE__=char", "__INT8_TYPE__=char", "__UINT16_TYPE__=short unsigned int" ],
Working on Ubuntu 16.04, GCC-ARM 7-2017q4-1 (PPA version)

[sean-mcmanus]

@SUlbrichA I assume you don't have the compileCommands set, right? If you have __UINT8_TYPE__ in your defines list why do you expect the #ifndef to have its contents grayed out? Have you tried running arm-none-eabi-gcc -Wp,-v -E -xc -dD -x c++ /dev/null and making sure the system include paths are all there and in the correct order? We're fixing it so that the defines shown are included (and you can specify the compiler), but until we ship that fix you may need to manually add any required defines (e.g. __GNUC__=7). I assume your intelliSenseMode is "clang-x64".

[SUlbrichA]

@sean-mcmanus I have not set the compileCommands (I use plain Makefiles). I'll look into creating it manually. I do not understand your second question: if it is defined in the json file the #ifndef makro should not expand and be grayed out (which works as expected except for the system includes in /usr – the defines do not work there; Peek: "no definition for __UINT8_TYPE__" ). I updated system include paths according to Arm-GCC's output as suggest and added "__GNUC__=7" – no effect.

[sean-mcmanus]

I wasn't suggesting you use a compile_commands.json -- we currently don't query for the system defines and don't have a way to add those manually, so it may not work as well for you (until our next release fixes it). compile_commands.json can be automatically generated via using cmake (I don't think manually trying to create is advisable because it can be very large).

The define is in your json file, which means it should be picked up by our IntelliSense compiler and the text should not be gray, because ifndef should evaluate to false.

The Go/Peek to Definition feature is currently implemented completely separately from the IntelliSense features and uses the recursive browse.path (parses global symbols in a files), but inactive code blocks and hover and error squiggles are from includePath/defines settings (parses the full translation unit).

[attdona]

Just to add another example of this issues with a minimal snippet (it took time to understand this side effect in a real project with a lot of includes and the macro define distant from uint8_t type declaration):

#include <stdint.h>

//#define PIPPO  static __inline

uint8_t myInt;

PIPPO uint8_t myf(void);

If the #define PIPPO is commented you have red marker, as expected, on last line (PIPPO undefined) but as a side effect you have red marker also on uint8_t myInt (variable "uint8_t" is not a type name).

Commenting out #define PIPPO resolve both errors.

[bobbrow]

This should be covered by #1293.

[kbumsik]

Look at the below bobbrow's comment for insider VS Code. This is for old VS Code version.

========================================================

Let me sum up this for TLDR;

1. For arm-none-eabi-gcc users, its compiler include path should be included first. It differes in each system. Use the verbose arm-none-eabi-gcc -v flag to see include list:

"includePath": [
    "/usr/lib/gcc/arm-none-eabi/7.3.0/include",
    "/usr/lib/gcc/arm-none-eabi/7.3.0/include-fixed",
    "/usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include",
    "/usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0",
    "/usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0/arm-none-eabi/armv7e-m/fpu",
    "/usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0/backward"
]

1. VS Code currently don't detect internal GCC definitions. We need to manually include them. This is why OP's problem occurs. To see the GCC's definitions use (for ARM Coretex M4 with hard FP):

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -E -dM - < /dev/null | sort

Then you need to add all definitions printed to "defines". Note that you also need to convert #define DEFINE VALUE to DEFINE=VALUE format. The definitions list is very long but it should be quite easy to convert the format using VS Code!

This is a c_cpp_properties.json example for Cortex M4F with hard FP.

[bobbrow]

@kbumsik #1293 would be a better issue to comment on since this duplicate is closed. FYI, we have posted a preview build on the Releases page that allows you to specify your compiler and arguments which addresses your two points (though in the insiders build there is a bug with the multiple arguments support which will be fixed in the final release).

You should not need to copy all of the #defines to your c_cpp_properties.json with the new release. You simply need to add

"compilerPath": "arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard"

to your c_cpp_properties.json and we will automatically include the default #defines and system include paths to the configuration when we parse your source files (e.g. you can delete them from "includePath" and "defines" after setting "compilerPath")