CDT/User/HowToTroubleshootCDTIndexing

Warning: This page is a work in progress (it started as a simple response on bugzilla)

Unresolved symbols

In case of semantic errors reported such as "Symbol 'foo' could not be resolved"

First, I would check if there are any unresolved includes that would be involved with those symbols being declared. To reduce the noise, you can set the Indexer preference to disable "Index unused headers" and disable "Index source builds not included in the build". Then reindex (it should do so automatically). You can see the unresolved includes by right-clicking on a project > Index > Search for Unresolved Includes. You can also use the view "Include Browser" to help you understand what the indexer sees as header dependencies. If an include path is missing, see the section further.

Then, I would inspect the headers to see if the symbols are not in inactive preprocessor regions. If they are in inactive regions but should be active, it's possible that you are missing some defined macros, either from the build output parsing or the detection of built-in macros (those are the typical sources that feed the indexer).

To see if the indexer is truly missing macros or includes, you can create a parser log, by right-clicking on a source file (not header) > Index > Create Parser log file. You can see there if the macros and includes you expect are there.

Then how to troubleshoot missing macros or include paths will depend on the type of project you created. If you created a managed build project, you should start by checking project properties > C/C++ General > Preprocessor Include Paths, macros. Under the entries tab, check that the entries are what you expect. On Linux, I would expect you have the "CDT GCC Build-in Compiler Settings" enabled. For this one, a common problem is that the -std flag is not passed. You can just add/hard-code it in the configuration of this provider under the "Provider" tab next to Entries. Any other flags that affect built-in macros might be important here but -std is usually the biggest culprit.

If you rely on the build output to parse macros/include paths, you should redo the same exercise and open the properties dialog on the problematic source file (not the project) but instead look at the entries under the provider called "CDT GCC Build Output Parser". If they are not what you expect, double check the configuration of this provider, for example, the regex might not parser a gcc with a custom name.

If all macros and include paths look OK in the parser log, there are further possibilities. If the unresolved symbol is in the middle of a syntax error, it might be a bug in the parser. If there is a