Eclipse on Windows shows error markers for cpp file but not for c file when I include freertos/FreeRTOS.h but build succeeds anyway (IDFGH-5757) (IEP-513)

[davidlehrian]

Environment

• Development Kit: ESP32-DevKitC
• Kit version DevKitC: v4
• Module or chip used: ESP32-WROOM-32D
• IDF version: v4.4-dev-2594-ga20df743f
• Build System: CMake 3.20.3
• Compiler version: esp-2021r1-8.4.0
• Operating System: Windows 10
• Using an IDE?: Yes Eclipse Operating System: windows 10 Java Runtime Version: 15.0.1+9 Eclipse Version: 4.20.0.v20210611-1600 Eclipse CDT Version: 10.3.0.202104042017 IDF Eclipse Plugin Version: 2.2.0.202108110455 ESP-IDF v4.4-dev-2594-ga20df743f Python set for IDF_PYTHON_ENV: Python 3.8.10 Python declared in PATH variable: Python 3.9.5
• Power Supply: USB

• Problem Description

Eclipse IDE is showing an error marker in a cpp file but the same code in a c file does not produce the error. Both files compile without error.

Expected Behavior

I should not be seeing an error marker in the cpp file.

Actual Behavior

I am seeing an error marker in the cpp file.

Steps to reproduce

1. Create a new project from the sample_project template.
2. Create the following test_function.c and test_function.h files.

   
   /* this is a test file */

include

void test_function_a();

include <freertos/FreeRTOS.h>

include <driver/gpio.h>

include "test_function.h"

void test_function_a(){ gpio_pad_select_gpio(26); gpio_set_direction(26, GPIO_MODE_OUTPUT); gpio_set_level(26,0); }

3. Compile the project and notice a clean compile and there are no error markers in Eclipse IDE.
4. Create the following TestClass.cpp and TestClass.h files

/ test class /

include

ifndef CLASS_TestClassH

define CLASS_TestClassH

class TestClass { private: TestClass(); uint8_t GPIO; public: TestClass(uint8_t pin); void testMethod(); };

endif

/ test class /

include <freertos/FreeRTOS.h>

include <driver/gpio.h>

include "TestClass.h"

TestClass::TestClass(uint8_t pin){ GPIO=pin; }

void TestClass::testMethod(){ gpio_pad_select_gpio((unsigned char)GPIO); gpio_set_direction((gpio_num_t)GPIO, GPIO_MODE_OUTPUT); gpio_set_level((gpio_num_t)GPIO,0); }

5. Compile the project and notice a clean compile however Eclipse is marking lines 11, 12 and 13 with error markers.

![EclipseError](https://user-images.githubusercontent.com/10326408/130654647-09a83aaa-f2c0-42d0-8170-e1c043170fd6.PNG)

6. Now comment out the the first include line in TestClass.cpp 
`//#include <freertos/FreeRTOS.h>`
7. Notice the error markers go away.

![EclipseNoError](https://user-images.githubusercontent.com/10326408/130654822-ecb9d5e1-daf6-4684-8f8b-679ea9a7da51.PNG)

8. I have tried right clicking on the project and selecting Index-> Rebuild but it doesn't help.
9. I know the example isn't using anything from <freertos/FreeRTOS.h> but I was trying to use taskENTER_CRITICAL and taskEXIT_CRITICAL in another project and that is when I came across this problem.  This example is a simple example that recreates the problem without including all the other extraneous code from my project.  

[brianignacio5]

Are you using the idf-eclipse-plugin ? You can check the README configure CMake toolchain to set it up.

[davidlehrian]

I am using the idf-eclipse-plugin and the environment variables were set up correctly by

Help > ESP-IDF Tools Manager > Install Tools

when I installed the system. I am able to successfully compile and flash a device so there is no problem with my installation as far as I can tell. I came across this error when I took a set of functions I had written, that work just fine as functions, and turned them into a class. The class I created will compile and work just fine too. The issue is that Eclipse seems to think there is an error when I include <freertos/FreeRTOS.h> in the class, but it doesn't when I include it in the function. Here is the file with the functions in them.

It seems there is something funny with how the idf include is processed by the indexer when included in a cpp class.

[davidlehrian]

Out of curiosity can anyone reproduce this issue? If not then it has something to do with my configuration and I'll work to figure out what is wrong.

[sigmaaa]

Hi @davidlehrian

what do you have in CMakeLists.txt which is in the main folder? try this:

set(srcs "main.c"
    "test_function.c"
    "TestClass.cpp"
    )

idf_component_register(SRCS ${srcs}
                    INCLUDE_DIRS ".")

[davidlehrian]

Thanks for the suggestion. Here is my CMakeLists.txt

idf_component_register(SRCS "main.c" "test_function.c" "TestClass.cpp"
                    INCLUDE_DIRS ".")

Your CMakeLists.txt does not change the behavior of the markers in Eclipse, but I see what you did there and I will use your format because it looks cleaner ;-)

[davidlehrian]

I was just playing around I discovered something new. It doesn't seem to matter what file I include from freertos I get the same markers. For example if I include <freertos/task.h> instead of <freertos/FreeRTOS.h> the error markers show up.

//#include <freertos/FreeRTOS.h>
#include <freertos/task.h>
#include <driver/gpio.h>
#include "TestClass.h"

TestClass::TestClass(uint8_t pin){
    GPIO=pin;
}

void TestClass::testMethod(){
    gpio_pad_select_gpio((unsigned char)GPIO);
    gpio_set_direction((gpio_num_t)GPIO, GPIO_MODE_OUTPUT);
    gpio_set_level((gpio_num_t)GPIO,0);
}

[davidlehrian]

I was able to find a solution to this issue. Not sure why this works, but if I move the include of gpio.h above FreeRTOS.h the error markers go away. This fixes the problem.

#include <driver/gpio.h>
#include <freertos/FreeRTOS.h>
#include "TestClass.h"

TestClass::TestClass(uint8_t pin){
    GPIO=pin;
}

void TestClass::testMethod(){
    gpio_pad_select_gpio((unsigned char)GPIO);
    gpio_set_direction((gpio_num_t)GPIO, GPIO_MODE_OUTPUT);
    gpio_set_level((gpio_num_t)GPIO,0);
}

Why does the order of the includes seem to make a difference?

[sigmaaa]

Hi @davidlehrian,

thanks for providing details. The order of the includes should not make a difference in this case. We already have some changes on the master branch and some PR related to the indexer. These changes are also fixing your problem. I will provide you a build after proper testing everything

[davidlehrian]

Thanks for the update!

[kolipakakondal]

Hello All, Fix is available as part of the IEP 2.4.0 release. Please get the latest changes using the update site to verify. Thank you.

[Richard-CRT]

I assume I might be doing something wrong, but I'm still seeing this exact behaviour using Espressif-IDE 2.10.0 with ESP-IDF 5.0.2 (installed today). Fixed by moving the driver/gpio.h include above freertos/FreeRTOS.h

[mbratch]

I continue to have this behavior on Eclipse 2023-09 running with ESP-IDF 5.1.1 and version 2.11.1.202310270725 of the Espressif plugin. It's been very frustrating. I've wrestled with the indexer issues for a couple of years. In that time there have been one or two times the problem magically nearly disappeared but then would come back. This is all on the same project through its history. I've tried just reimporting the project from scratch and reinstalling the Eclipse tool with plugin but that didn't solve it.

[kolipakakondal]

I continue to have this behavior on Eclipse 2023-09 running with ESP-IDF 5.1.1 and version 2.11.1.202310270725 of the Espressif plugin. It's been very frustrating. I've wrestled with the indexer issues for a couple of years. In that time there have been one or two times the problem magically nearly disappeared but then would come back. This is all on the same project through its history. I've tried just reimporting the project from scratch and reinstalling the Eclipse tool with plugin but that didn't solve it.

Hi @mbratch Unfortantely Eclipse CDT Indexer is not actively maintained, doesn't support C/C++ 20 lang features but some of these features are used in the ESP-IDF 5.0 and higher versions, hence you see indexer parser issues in IDE.To avoid all these problemss we are recommending to use clangd indexer, please use these instructions to confgure in the Espressif-IDE. Going forward, will set this as the default option in the Espressif-IDE.

[mbratch]

Hi @mbratch Unfortantely Eclipse CDT Indexer is not actively maintained, doesn't support C/C++ 20 lang features but some of these features are used in the ESP-IDF 5.0 and higher versions, hence you see indexer parser issues in IDE.To avoid all these problemss we are recommending to use clangd indexer, please use these instructions to confgure in the Espressif-IDE. Going forward, will set this as the default option in the Espressif-IDE.

Hi @kolipakakondal , thank you for the quick reply. I was not familiar with this news. I will try the clangd indexer.

[Jaboop8]

I continue to have this behavior on Eclipse 2023-09 running with ESP-IDF 5.1.1 and version 2.11.1.202310270725 of the Espressif plugin. It's been very frustrating. I've wrestled with the indexer issues for a couple of years. In that time there have been one or two times the problem magically nearly disappeared but then would come back. This is all on the same project through its history. I've tried just reimporting the project from scratch and reinstalling the Eclipse tool with plugin but that didn't solve it.

Hi @mbratch Unfortantely Eclipse CDT Indexer is not actively maintained, doesn't support C/C++ 20 lang features but some of these features are used in the ESP-IDF 5.0 and higher versions, hence you see indexer parser issues in IDE.To avoid all these problemss we are recommending to use clangd indexer, please use these instructions to confgure in the Espressif-IDE. Going forward, will set this as the default option in the Espressif-IDE.

Hi @kolipakakondal, I am having similar indexing issues. I tried following the steps that you linked above but ran into issues trying to set the clangd path. I used the ESP-IDF Windows Installer to install the latest stable build (ESP-IDF 5.1.2 with Espressif IDE 2.12.0). I then launched the Espressif IDE closed the welcome page and checked the Build Enviornment variables. For me they did not automatically configure maybe because this is not my only instance of ESP-IDF but I was able to manually add them by echoing the enviornment variables in the ESP-IDF 5.1 CMD and copying them into the Espressif IDE. I was then able to import a known good project build and add launch configurations.

Unfortunately I am stuck at this point. I installed the latest version of Eclipse CDT-LSP and the dependencies from the update site but then when I tried to add the clangd path I am unable to find it anywhere on my computer. I do not have a '.espressif' folder and I have checked the Espressif5.1.2 folder where I installed the ESP-IDF. Here I am able to find the GCC compiler path from the instructions but no clangd. Any idea where I can find this or if I am missing something obvious. I've showed a screenshot that is claiming everything should already be downloaded and up to date.

[kolipakakondal]

Hi @Jaboop8 It's part of the esp-clang toolchain, please check the screenshot below. I think this is available from the esp-idf 5.0 and higher versions.

[Jaboop8]

@kolipakakondal That is where I was hoping to find it. I see all those in the tools folder and a few more with the ESP-IDF 5.1.2 but not the esp-clang toolchain. Am I able to download that from somewhere else?

[davidlehrian]

@kolipakakondal I can confirm what @Jaboop8 is stating. When installing the Espressif IDE via the Offline Installer at this link the installation does not create a .espressif folder under the user's account like when using the Eclipse IDE and installing the Espressif plugin, but instead appears to use the tools and frameworks folders underneath the installation folder for the IDE which by default on Windows is C:\Espressif. I can also confirm that there is no esp-clang in the tools folder in the installation.

However, if you go to the Espressif IDE menu and choose ESP-IDF Tools Manager -> Install Tools it will install the esp-clang folder under C:\Espressif\tools and you can configure the IDE as described via the link provided.

Having done this I do get code completion for the ESP-IDF C language and the errors I was getting on ESP-IDF calls have gone away, but I am now getting errors on includes like <String> and <mutex> and when I attempt to run the program I get an error popup in the IDE stating there are errors and asking if I want to launch it anyway. I understand these are CPP libraries and we just installed a clangd file so it may not support cpp, but this fix seems to switch one set of clang errors for another set of cpp errors.

Also I do not get any context color highlighting in my cpp or h files like I get in my straight Eclipse installation which may be due to a plugin not being installed in my Espressif IDE that I have in Eclipse IDE. I am going to look at this a little more closely and will provide an update.

[kolipakakondal]

@kolipakakondal I can confirm what @Jaboop8 is stating. When installing the Espressif IDE via the Offline Installer at this link the installation does not create a .espressif folder under the user's account like when using the Eclipse IDE and installing the Espressif plugin, but instead appears to use the tools and frameworks folders underneath the installation folder for the IDE which by default on Windows is C:\Espressif. I can also confirm that there is no esp-clang in the tools folder in the installation.

Thanks for reporting this. Let me take a look. @Jaboop8 Can you try ESP-IDF Tools Manager -> Install Tools and see if you are able to see esp-clang tools.

I am now getting errors on includes like and

@davidlehrian Did you set the clangd drivers path in the preferences? Please check this https://github.com/espressif/idf-eclipse-plugin/issues/861#issuecomment-1849309369

[Jaboop8]

Thanks for reporting this. Let me take a look. @Jaboop8 Can you try ESP-IDF Tools Manager -> Install Tools and see if you are able to see esp-clang tools.

@kolipakakondal I am having trouble setting the paths to Install the tools. I've tried what is below in the screenshot and I have tried the ESP-IDF path as being 'C:\Espressif5.1.2\frameworks\esp-idf-v5.1.2' and 'C:\Espressif5.1.2' for both sets of Git and Python paths but am getting errors for both. What paths am I supposed to be using?

This is the error I am seeing. I do see a tools.json at this file at path: C:\Espressif5.1.2\frameworks\esp-idf-v5.1.2\tools\tools.json but not sure if this is the same file the install tools is trying to find.

I then tried using the tool installation wizard and this seems to have partially worked but ends up throwing the same error towards the end of the process. I now have a .espressif folder but no clang bin.

[davidlehrian]

@kolipakakondal I can confirm that after changing the "Drivers" path to C:\Espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-*.exe that the errors I was seeing for the cpp libraries have gone away and that command completion is indeed working for both the ESP-IDF c libraries as well as my own cpp files.

The only thing that I have not been able to get working is Syntax Coloring. I thought that was maybe accomplished via a plugin but it seems to be under Editor->Syntax Coloring. Is there a way to make this work with Editor (LSP)?

[davidlehrian]

@Jaboop8 It looks like you don't have git installed. "WARNING: Git was not found". Looking at idf_tools.py it uses git during installation to check the version of the IDF hence the error. You can download it from here. That is the version I have installed and it seems to work.

[Jaboop8]

@kolipakakondal @davidlehrian Figured out the errors I was seeing this morning to get the tool installer to load but I still do not have the clang binary in the .espressif folder. I do have it at this path now: C:\Espressif5.1.2\tools\esp-clang\15.0.0-23786128ae\esp-clang\bin\clangd.exe. Should it work fine to use this for the path in the IDE?

Tool Installer Issue: I do have git installed but it was an older version so I went ahead and updated to the 2.43 version you linked. I still see the same issue though. It looks to me like the issue is happening because it is searching for non-existent paths. It seems like it thinks there should be a 'src' folder at this level that is not there.

I tried adding one and putting everything inside of 'src' but then I get a different error.

Tool Installer Solution: I copied the folders below into a src folder and put them at the same folder level as the Espressif5.1.2 folder

Not sure why these files needed to be in both places but resolved the issue with the scripts looking for the paths like: '../../../../src\tools/tools.json'.

[davidlehrian]

@Jaboop8 It seems that Espressif IDE no longer uses the .espressif folder under your user folder but uses C:\Espressif instead. This seems to have changed with version 5.1.2 of ESP-IDF as I did have one with version 5.1.1 of ESP-IDF. So I wouldn't worry about. Use the one that is installed in C:\Espressif as that is what I am doing and it is working fine. Albeit without syntax coloring, but that is a separate issue that I opened here #892. I did set my "Drivers" to C:\Espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-*.exe so that it would catch c++ libraries as well as the c libraries.

Another thought, did you create a new workspace when you launched Espressif IDE or did you reuse and old one from perhaps version 4 of the EDP-IDF? If you used an old one try creating a new one and installing the tools from there. I know there were a lot of changes between versions 4 and 5 and as I recall I had to create a new workspace, but it was quite a while ago so I don't remember exactly.

Looking at idf_tools.py this call seems to be using a variable global_idf_path which can be set via an environment variable IDF_PATH. Do you have this environment variable set? If so it may be pointing to the wrong location. There is the call on line 2674 right before your errors are generated where global_tools_json = os.path.join(global_idf_path, TOOLS_FILE). It appears that in your case it is using ../../../../src as the global_idf_path. The only way for global_idf_path to be set is either from passing it on the command line, which I am not seeing in your error, OR from the environment variable.

[Jaboop8]

@davidlehrian I am using a new workspace for the 5.1.2 ESP-IDF version.

I think I am getting close to where you are at now. I have no syntax coloring and I can't use standard keyboard shortcuts like 'Ctrl+/' to comment things out. However, I am also seeing errors on a lot of the sample code mostly with undeclared structs and a lot of implicit declaration errors. This project I am testing builds when I am not using the clangd but obviously has the error marking issues this is supposed to be resolving. I do see that warnings are being treated as errors. Maybe this is the difference, if there is a way to turn this off for now I could test and see if I am at least successfully building again. Seems weird that the idf example projects would have warnings that are being treated as errors though so maybe I'm still missing something.

That does explain the path issue I was having. There was an old environment variable set with that IDF_PATH. It was being overwritten anytime I ran the ESP-IDF 5.1 CMD terminal so I wasn't seeing it when I checked the path in there.

[davidlehrian]

Glad you figured out the path/environment variable issue.

Regarding the warnings you are getting, this is the result of the Drivers path setting in Preferences->C/C++->Editor (LSP)->clangd. The link provided that explains how to set up clangd says to set the Drivers to C:\Espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-gcc but this driver doesn't resolve C++ files only the IDF C files. There is a discussion about this in issue #861. I have found that the best value to use for the Drivers setting on windows is:

C:\Espressif\tools\xtensa-esp32-elf\esp-12.2.0_20230208\xtensa-esp32-elf\bin\xtensa-esp32-elf-*.exe

This resolves C as well as C++ libraries and I can compile all my code and examples with warning.

[Jaboop8]

@davidlehrian I saw your note on this. I am using the same Drivers path but I do still see errors.

[davidlehrian]

Do you have the .clangd file in the root of your project folder? It needs to contain:

CompileFlags:
  Remove: [-fno-tree-switch-conversion, -fstrict-volatile-bitfields]

If this doesn't exist there will be an error at the first comment in the file.

[Jaboop8]

@davidlehrian I have the .clangd file. I just tested some other example projects and they are compiling fine. It seems the one I was working with the issue is around websockets. It looks like 90% of the errors are being thrown around this 'httpd_ws_frame_t' struct that is not resolving.

I have the websocket support enabled in the sdkconfig but maybe there is something else weird with websockets. The only place I see this referenced is in the 'esp_idf_components/esp_http_server/src/httpd_ws.c' but looking at this it seems that the struct is actually defined in the 'esp_http_server.h' which is the include not resolving in the 'httpd_ws.c'. Is this just a component registration issue?

I found the definition in the ESP-IDF v4.4.2 since it is easier to find things with the indexer enabled and verified its in the same spot in the v5.1.2 but not sure why it doesn't resolve maybe this is just some CMake issue I'm not understanding though and not actual clangd setup.

[davidlehrian]

Hmmm, odd. I just created a new project from their template wss_server which is their HTTP server with web socket support for ESP32. It is located under protocols\https_server\wss_server. After adding the .clangd file to the root of the project, it compiled without warning or error. I was able to start typing httpd_ws_frame_t and clangd found it and I was able to create a variable of this structure type. Can you try creating and compiling this example?

[Jaboop8]

This is working for me too starting with a fresh example.

I guess the thing I have to figure out now is why the Import tool isn't working to bring in a project that was from v4.4.2 and get it to compile in v5.1.2. I took a look through the project settings and saw the linked sources were doubled up with both the v4.4.2 and v5.1.2 components so I went ahead and deleted the v4.4.2 linked references but am still seeing issues.

@kolipakakondal Any advice on importing projects from older ESP-IDF versions?

The other common error I am seeing is with sprintf formatters. Sort of weird too I see a lot of these errors but looking at the example below uint32_t is being labeled as 'long unsigned int' in the error message but as 'unsigned int' by clangd in the editor so no matter which formatter I use '%u' or '%lu' I am getting an error message for both. Also when I try to use the '%lu' formatter like the error message suggests I get a recommended fix to change it back.

[davidlehrian]

Upgrading from 4 to 5 I was not able to import the project directly. What I did was create a new workspace and check out my source code from the repository and then import the project from the source.

I think you might be able to get away with deleting the build folder and the .project and .cproject files from the directory, deleting the project from the workspace and then importing it. The project definitely has to be deleted from the IDE as I recall 4 created some sort of linked folders in the IDE to the ESP-IDF files which isn't done any more. This folder didn't exist on disk only in the IDE. I think doing this would also clear up the linked references to which you are referring.