Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indexer will not resolve includes in unit-test code (but will still compile and run) (IEP-1164) #891

Open
Vincent-Dalstra opened this issue Jan 27, 2024 · 1 comment

Comments

@Vincent-Dalstra
Copy link

Vincent-Dalstra commented Jan 27, 2024

This came up while trying to implement unit-testing (https://github.com/espressif/esp-idf/tree/master/examples/system/unit_test).
The eclipse indexer will show "unresolved include" errors for esp-idf headers and system headers (e.g. "unity.h", <limits.h>). It will also show errors for symbols which are defined in those files ( e.g. TEST_CASE)

However, the test program will still build, flash, and run the tests.

To Reproduce
A fresh install + example project (system/unit_test) was sufficient to produce this error; see below:

Steps to reproduce the behavior:

  1. Download and unpack the latest Espressif IDE (in my case: https://dl.espressif.com/dl/idf-eclipse-plugin/ide/Espressif-IDE-2.12.0-linux.gtk.x86_64.tar.gz)

  2. Run "espressif-ide", and create a new workspace

  3. Run the "Tools Installation wizard" to install the tools and latest esp-idf (in my case: esp-idf-v5.1.2)

  4. File->new->Espressif IDF project

  5. Select template "system/unit_test" and leave the name as default ("unit_test")

  6. Open the project, select "esp32s3" as the target, pick the correct port.

  7. Press "Launch in run mode". (The normal application will build, flash, and run on the esp32s3).

  8. Running the ESP-IDF serial monitor shows the output - matches what I would expect from the program.

  9. File->import

  10. Select "Espressif/existing IDF project"

  11. For name: "unit_test_test"

  12. For "existing project location", select the "test" folder in the current workspace, and make sure "copy project into workspace" is not ticked.

  13. Open the test folder

  14. Change the launch configuration to "unit_test_test", select esp32s3 as the target, and pick the correct port

  15. Press "Launch in run mode". (This will launch and flash the test program to the esp32s3 dev board).

  16. Running the ESP-IDF serial monitor shows the expected output as seen in README.md, indicating that the test program is running.

  17. Open the file "components/testable/test/test_mean.c"

  18. The linter highlights 5 errors: 2x "unresolved inclusion", 3x "Syntax error"

  19. Ctrl+left clicking either or "unity.h" gives "Could not find include file unity.h on include paths"

  20. Same result for <limits.h>, but not for "testable.h", which opens normally.

Expected behavior
There should be no errors in that file.

The compiler is able to find the files, so it is not apparent why the indexer cannot. The spurious errors make it difficult to write tests.

Screenshot from 2024-01-27 14-05-26

Successful workarounds

  • Setting up the LSP editor and CLang (and turning off the regular indexer in the process) would correctly index the file.
  • Not with a fresh install; something else I did helped, but I don't know what...

Unsuccessful

  • Adding "REQUIRES unity.h" to the adjacent CMakeLists.txt file

Espressif-IDE Product Information:
Espressif > Product Information (Copy content from the console and attach as a file)

ESPIDF_product_info.txt

Eclipse Error log:
Window > Show View > Other > Search for "Error Log" (Attach as a file)

Espressif_IDE_errlog_2024-01-27.log

@github-actions github-actions bot changed the title Indexer will not resolve includes in unit-test code (but will still compile and run) Indexer will not resolve includes in unit-test code (but will still compile and run) (IEP-1164) Jan 27, 2024
@Vincent-Dalstra
Copy link
Author

Vincent-Dalstra commented Jan 28, 2024

Upon further digging, looks like the issue matches this: #107

Getting similar results in the parser log files.

That issue was closed without a fix, more of a "don't do this" instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant