Indexer in V4.4.0 is Seriously Flakey with ESP32 Code #1491
Comments
|
Had the same issue with AVR and STM32, so seems not to be platform specific. close sloeber, delete indexer settings in the projects .prefs file, restart sloeber, select project->Indexer->Rebuild Index |
|
please try the nightly to see if the problem still exists |
Jantje, I will try. But, I'm not a tool chain guy and I don't know how to "build" anything. Do I just click on "windows" and download the .zip? Then, click on "sloeber-ide.exe"?
|
|
you will have to expand the zip file before opening sloeber-ide.exe. On windows best to expand as close to the root as possible to keep path lengths small. |
|
OK, thanks. That's how I install all versions of the Sloeber Product ... in their own directory right under root, each with their workspace directory (also right under root). |
|
With the latest nightly (from the update server 4.4.1.202207120021) there are still some hickups with unresolved references showing up every now and then This is really a great relief ! |
|
Sorry, but after a while now it is back to the original state where the indexer stopped working. |
|
I'm sorry to hear this. |
|
hmmm, where would I find that logfile? |
|
in the menu windows->show view->other->error log You can right click in the view and select export log |
|
the log is VERY big (985kb) but in a timeslot where I THINK that I tried the index rebuild, there are lots of the same errors:
I cleared the log and will have an eye on it when it occurs again |
|
hmmm, that error appears also when the index is rebuilt properly :/ |
|
The no propertytester gnumcu is gui related. It should be fixed by CDT (as gnu mcu is now part of cdt and it is a plugin dependency error) I should work around that (but I don't know how). But it surely is not related to indexing. |
|
now it happened again. sloeber was open, I closed and reopened the project (which closed all open files as well) and after reopening the project and a file, syntax coloring did not happen, call hierarchy, reference searching etc. don't work. Second file too. Rebuilding index did not start, F5 also with no effect. But there is nothing in the error log, only the bespoke and unrelated property tester message. |
|
found a menu option on sourcefile right-click -> index - create parser log here's the output: this is interesting: nevertheless nothing happens when I try
|
|
Are you sure this is not a casing issue Arduino.h versus arduino.h or something like that? |
|
nope, not sure! I will try in a xubuntu VM |
I can 100% sure guarantee that it can. |
|
Thanks for clarifying this! Any hint where I could start looking? |
|
yes and the list of unresolved headers is IMHO a complete list of possible issues. |
|
just a thought on this: if it builds without problem on Linux, can I rule out a casing issue? |
|
Yes |
|
So, is there a solution? This bug really limits the usefulness of Sloeber when working with ESP32 code. The "Open Declaration" function is probably the feature I use most. As things are now, that fails often even though the code compiles totally error-free. |
|
The root cause has still not been identified. |
|
a clumsy and not always working workaround is to close and re-open sloeber... |
Even that rarely works. |
|
Have you tried to trigger the discovery? |
|
Today I tried this with https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_dev_index.json |
|
Despite the title beeing for ESP32, I experience the same indexer misbehaviour for STM32. Created a new project, add some very simple code (read inputs and write to serial) I then did the steps you wrote a few weeks back to trigger the discovery:
And well, it worked! |
If there is an indexer issue SrcWrapper.h will not be added automatically.
Great to see my assumption -that this problem is related to discovery failing- confirmed.
Is there an error in the error log? And if this happens again and you have activated the console log. Can you provide the discovery console log and the error log here? |
|
Hmm, strange that box is checked... I had a correct index, changed some sloeber setting (in project properties -> sloeber -> Optimize from -O3 to -O0) and after that the index and syntax coloring was broken. Here's what is in the console now: |
|
Can you create the file |
|
hmm, that file already exists (created 6 minutes after the above project settings change the corrupted the output) content of the file build.opt: |
|
I think this makes sense |
yes, after clicking "apply & close" a lot happens in the GUI and among these happenings the release folder disappears. I deleted the whole release folder and triggered discovery via the nothing happened, maybe some very quick actions that my eye didn't catch... I then did a clean build, and triggered the discovery again. as of yet I still have not found clearly what has to be done to recover the index... mostly a combination of a clean build and triggering the discovery works. |
You have to jukebox the consoles. It is not really user friendly and error prone. A fool proof full functionality supporting workaround won't be easy. And this problem needs it's own issue as it is different form the original issue. |
|
well, it seems that the STM32 implementation needs that specific line... Shall I open a new issue? If so, I need assistance in finding an appropriate title and description since I don't know enough about the specifics of what goes wrong here... |
|
there is no file name in the error so this is probably caused by a double space :-( |
|
sorry. That work around won't fly. I can't test here on this machine as this machine is a work in progress. |
Is it possible to tell in which command/file the double space could be? I can search for it, but due to lack of knowledge don't know where to start looking... |
jantje
added
importance: usability
OS: all
domain: configuration
|
I provided a workaround in the issue #1534 which is about the opt file problem. |
|
This issue is marked "fixed in the nightly". Yet it persists in Stable Product v4.4.1. Does this Stable version pre-date the "nightly" in which the fix was implemented? Also the workaround of "project properties->pre processor includes->providers->arduino compiler settings->Command to get compiler specs. change it (add a space) |
|
Things marked fixed in nightly are not yet released. |
WOW, this works a lot better than previous versions. Thanks!!!! I notice it also seems to fix This Problem The only "Fake Errors" I'm still getting now are those associated with the data structures and functions in the file "esp_camera.h". The code compiles error-free but the Indexer simply doesn't "see" anything in that file. Perhaps it's because of the file's location? This is were it is in the installation directory: D:\SloeberNightly230109\arduinoPlugin\packages\esp32\hardware\esp32\2.0.6\tools\sdk\esp32\include\esp32-camera\driver\include Is it possible to also make the Indexer look there? Thanks again. |
Not sure why that would be fixed but I had to a add "completely ignore pre build errors" for esp8266 :-( ; maybe that is related. If the build finds the esp_camera.h file the indexer should find it to. You can see what the discovery found in project properties->C/C++ General->Entries As a workaround you could try to add the path to the include paths. |
|
I'm seeing something similar with the latest nightly build (as of 2023-08-08) and the arduino-esp32 SDK. From the indexer's console output (as mentioned above) it appears that (for ESP32) the indexer is only looking at files provided by Edit: Deselecting |
|
For whatever reason, this issue is back for me (existing project) with a 4.4.3 release and also the 5.0 nightly ... |
|
Strange.
I completely forgot about this one and it is for sure not in V5.0. I hope this is not needed in V5.0 |
|
well, after a fresh install of 4.4.3, indexing seems to be correct again ! will check for V5.0 tomorrow |
|
Before checking V5 for esp32 wait for a fix for "exclude from build" |
|
My issue is not related to ESP32, I am on STM32 |
|
STM32 in general behaves better than esp32. |
With just about any ESP32 code, will usually get tons of fake “… unresolved” errors even though the code compiles totally error-free. I’ve played with all the check boxes under Window --> Preferences --> C/C++ --> Indexer. I’ve tried deleting the errors in the “Problems” tab, Clean Project, Recompile, Build All, Close Project, Close Sloeber, etc.
Then for no apparent reason, most of the fake errors might go away. Or, they may stay permanently.
Can’t find the right Kabuki Dance to make it work all the time.
The text was updated successfully, but these errors were encountered: