Platformio-vscode-ide: identifier "uint8_t" is undefined

[janLo]

I get all uint8_t and uint16_t declarations marked as errors with identifier "uint8_t" is undefined in my platformio-project for an ESP8266. It can easily be reproduced: Just generate a new project for an esp8266 board, choose arduino as framework and type uint8_t x = 3 somewhere. It will hilight uint8_t and tell its an undefined identifier.

This does not happen on AVR projects for example.

I spend quite some time to debug this issue and found this line be responsible in my c_cpp_properties.json at the includePath array:

           "/home/jan/.platformio/packages/toolchain-xtensa/lib/gcc/xtensa-lx106-elf/4.8.2/include-fixed",

Deleting this fixes the issue.

[mrvadim]

It doesnt fix the issue. I get new error "cannot open source file "limits.h""

[ivankravets]

@sean-mcmanus could you explain to us what is missed now?

platformio.ini

[env:nodemcu]
platform = espressif8266
framework = arduino
board = nodemcuv2

Simple code

#include "Arduino.h"
#include <limits.h>

uint16_t i;

void setup()
{
}

void loop()
{
}

1. uint16_t identifier "uint16_t" is undefined
2. #include <limits.h> - undefined include. See ~.platformio/packages/toolchain-xtensa/lib/gcc/xtensa-lx106-elf/4.8.2/include-fixed

[sean-mcmanus]

Ah, yeah, I also hit this issue. I'll let you know what I find out...

[ivankravets]

@sean-mcmanus PlatformIO is good for your team to test IntelliSense parser :) We have ~20 different dev/platforms with different toolchains/frameworks. All they work for "building" and should work for IntelliSense too.

[tmay]

I have run into this issue today too. any insight would be appreciated.

[janLo]

The solution I proposed still works for me. Limits.h is available from include without the -fixed .

[phhoef]

I have the same issue with the Arduino Due. Here is the platform.io config

[env:due]
platform = atmelsam
board = due
framework = arduino

When deleting the following line from the include_path as @janLo suggested, results in the same behavior. The uint8_t identifier is found, but limits.h and Arduino.h is not found.
"C:/Users/phoef/.platformio/packages/toolchain-gccarmnoneeabi/lib/gcc/arm-none-eabi/4.8.4/include-fixed"

[ivankravets]

We still wait for a feedback by @sean-mcmanus

[sean-mcmanus]

Sorry, I've been too busy trying to get our stuff working on 32-bit OS's...I'll investigate this again after I finish that.

[Dee-Fuse]

I've done some digging into the stdint.h and limits.h and traced the error down to missing definitions of __SCHAR_MAX__ and __SHRT_MAX__ in the includes-fixed/limits.h.
These are defined inside the xtensa gcc and the IntelliSense engine doesn't find them.
The workaround I've found is to add

"__SCHAR_MAX__=0x7f",
"__SHRT_MAX__=0x7fff"

to the defines: [ ... ] section of the c_cpp_properties.json file.
With this change you can reset the C_Cpp.intelliSenseEngine back to Default without getting the error.

You can print all built-in defines with the following command in Powershell:
PS C:\Users\<yourname>\.platformio\packages\toolchain-xtensa\bin> echo $null | .\xtensa-lx106-elf-gcc.exe -dM -E -

[bertmelis]

The fix introduces a lot of warnings when compiling:

warning: "__SCHAR_MAX__" redefined [enabled by default]
recurring in many files...

[Dee-Fuse]

I've seen it after the Travis tests.
After some Try&Error I have found some cases with the same compiler warnings.
Ther may be some libs which includess some headerfiles, which define this constants.
I'm going to search further to find the tweak that causes this behaivor of the IntelliSenseengine

[janLo]

If I remove the include-fixed it gets limits.h just from another place:

~/.platformio/packages % find toolchain-xtensa  -name limits.h -exec md5sum {} +
778d9444027fa170bbc983e69203bfe8  toolchain-xtensa/lib/gcc/xtensa-lx106-elf/4.8.2/include-fixed/limits.h
778d9444027fa170bbc983e69203bfe8  toolchain-xtensa/lib/gcc/xtensa-lx106-elf/4.8.2/install-tools/include/limits.h
5d185c0e0336f070af89a1e74e27eec5  toolchain-xtensa/xtensa-lx106-elf/include/c++/4.8.2/tr1/limits.h                                                                                          
ecb90a5cc3bf48ed9926ef8170214a9c  toolchain-xtensa/xtensa-lx106-elf/include/limits.h         

[Dee-Fuse]

In my case I get noticed that Arduino.h includes limits.h which can't be found.
At the moment it seems that the best solution would be to add the definition conditional to the top of includes-fixed/limits.h

#ifndef __SCHAR_MAX__
# define __SCHAR_MAX__ 0x7f
#endif

#ifndef __SHRT_MAX__
# define __SHRT_MAX__ 0x7fff
#endif

I've also removed the definitin from the c_cpp_properties.json and the main.py from my commit.
With this change I'm getting no compiler warnings and the intelliSenseEngine works correctly.

[janLo]

Maybe there is a misunderstanding, I didn't mean remove the include-fixed/limits.h - I just meant to delete the line from c_cpp_properties.json at the includePath array. The intellisense then takes this file from ~/.platformio/packages/toolchain-xtensa/xtensa-lx106-elf/include/limits.h which has working typedefs and defines.

[Dee-Fuse]

Now I've got you. But it only works once.
The problem is, VSCode regenerates the c_cpp_properties.json as soon as you hit the Compile button.

[janLo]

The intention of the bug was to fix this at that stage ;)

[Dee-Fuse]

So the solution would be to remove this entry from the c_cpp_properties.json.
But at the moment I don't know how to get rid of it.
Its defined inside the xtensa gcc und is parsed by the VSCode engine at some point (I think)
echo | .\xtensa-lx106-elf-gcc.exe -W"p,"-v -x c++ -

[sean-mcmanus]

@Dee-Fuse It sounds like you guys tracked down the missing define. The cpptools extension doesn't regenerate the c_cpp_properties.json. I think it's the platformio extension -- I think they shouldn't overwrite an existing c_cpp_properties.json and should rely on users deleting the file if they want the extension to auto-generate a new one.

[janLo]

@sean-mcmanus I think its not a missing define, I think its more a matter of using the wrong header files. I'm not sure of the files in ~/.platformio/packages/toolchain-xtensa/lib/gcc/xtensa-lx106-elf/4.8.2/ should be considered at all or if they should be left out, as they mostly mirror ~/.platformio/packages/toolchain-xtensa/xtensa-lx106-elf/include/. I think ~/.platformio/packages/toolchain-xtensa/lib/gcc/xtensa-lx106-elf/4.8.2/ might be gcc-specific detail thats not part of the public api. But I can be wrong.

[Dee-Fuse]

Insite the include-fixed folter is a README file describing the use of this headers.
I cant find the current toolchain in the esp8266 repository, but I found it in an stale one here
I like the idea of @sean-mcmanus not to regenerate the file. It should be handled like the platformio.ini
At the moment I'm not deep enough into the PlatformIO extension to figure out where the (re)generation ist started.

[ivankravets]

Guys, please open PIO IDE Terminal and type pio upgrade. Starting from PIO Core 3.5.0rc6 we will generate built-in GCC macros for configuration files.

All should work now.

[ivankravets]

Could we close this issue? Does it work for you now?

[bertmelis]

For me it works. All is good now.