Difference between revisions of "CDT/User/HowToTroubleshootCDTIndexing"

Revision as of 23:16, 7 October 2020

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

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 rebuild the index, which is should do automatically when you change preferences, otherwise right-click on the project > Index > Rebuild.

Doing a manual rebuild will output a useful report in the view Error Log (the view comes by default with the Eclipse for C/C++ package but might not be in your CDT distribution depending how you got it), you can also find the same report in under your "workspace/.metadata/.log" file.

Example:

 !MESSAGE Indexed 'mariadb-server' (1,784 sources, 3,493 headers) in 505 sec: 688,918 declarations; 4,042,030 references; 11 unresolved inclusions; 411 syntax errors; 66,635 unresolved names (1.4%)

You can see the list of unresolved includes by right-clicking on a project > Index > Search for Unresolved Includes.

• Screenshot*

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.

• Screenshot*

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.

Important limitations to the parser/indexer

• Language support is not nearly complete. In fact, at the time of this writing, C99, C++14, C++17, etc and later are not fully supported. Expect parsing errors due to this resulting in many different symptoms (syntax errors, symbols not found, etc). Support for new feature is not expected to improve drastically as the community is now small and efforts are put on language parsers such as Clangd.
• By default, the indexer only indexes *one variant* of a given header, if it detects "pragma-once semantics" (#pragma one of #ifndef FOO_H). If a header is meant to be included differently multiple times and it should declare new symbols, you might need to tell the indexer to explicitly to index all variants of this header. You can do so in the indexer preferences. Be aware that indexing all variants (especially of all headers) will incur a huge performance cost so this should be done sparingly. * screenshot*

Debugging CDT

See Getting started with CDT development

Using Oomph might be the quickest way to get started.

Classes of interest

• org.eclipse.cdt.internal.core.dom.parser.ProblemBinding: When you have a "Symbol 'foo' could not be resolved" error, put a breakpoint in the constructors of this class and you can work your way back in the stack where/why the parsing produced this.