Eclipse Community Forums: C / C++ IDE (CDT) » indexer not working on *.cpp files

Home » Language IDEs » C / C++ IDE (CDT) » indexer not working on *.cpp files(Indexer not resolving header files despite their pathways being in the include option location. )

Show: Today's Messages :: Show Polls :: Message Navigator

indexer not working on *.cpp files [message #1844693]

Wed, 22 September 2021 05:06

Nicholas Hathaway

Messages: 4
Registered: September 2021

Junior Member

I am having trouble with the indexer in a couple of my CDT projects where it isn't able to resolve symbols/headers but only for .cpp files. The majority of the .cpp files only have one header inclusion and that is it's accompanying header. The parser is able to do just fine on the header file but fails to resolve anything on the cpp file.

This is only happening for a couple of my CDT projects and it only started happening recently so I'm guessing it's something to do on my end but am posting here in case anyone can help.

I've tried downloading older versions of CDT/eclipse, I've tried creating a new project directory and setting up the project from scratch several times but have had no success. As for all my projects I've added '-std=c++17' to the Properties --> C/C++ General --> Preprocessor Include Paths --> Providers which was an issue of mine in the distant past but I don't think that's the issue cause it's working for the header files (.hpp) and in the parse log file for the cpp file I find "__cplusplus=201703L".

The odd thing too is the unresolved headers paths can be found underneath the Include Search Path (option -I): section in the cpp parser file so I'm not sure why they can't be resolved.

I've attached the parser log files for both a cpp file and the hpp file it includes.

I've bashed my head against a wall for several hours on this so any suggestions for what else to look into would be greatly appreciated, thanks!

Attachment: GatheringUtils_hpp_parser_log.log
(Size: 32.65KB, Downloaded 58 times)
Attachment: GatheringUtils_cpp_parser_log.log
(Size: 108.64KB, Downloaded 38 times)

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844721 is a reply to message #1844693]

Thu, 23 September 2021 04:50

David Vavra

Messages: 1427
Registered: October 2012

Senior Member

You need to setup include paths for the Indexer just as you would need to for the compiler.
The Indexer and compiler are completely independent.
The Indexer include paths are set by
Project --> Properties --> C/C++ General --> Preprocessor Include Paths, Macros etc. --> Entries tab --> CDT UserSettings Entries

For example, you are attempting to include (in GatheringUtils.hpp),
SeekDeepPrograms/SeekDeepProgram/SeekDeepSetUp.hpp
which has to be relative to one of the items in the include path list.
The parser log is saying it couldn't be found.

go the the CDT UserSettings Entries,

click Add
select the path type <project>, <workspace>, or <file system>
from the dropdown in the upper right
enter the directory containing your headers or browse for it
click OK

I think this only accepts one entry per add.
You will probably need to rebuild the index after setting all of the paths.

You could try using
Project --> Properties --> C/C++ General --> Paths and Symbols
That's supposed to merge telling the compiler and Indexer in one place.
If you do, you will need to enable the CDT Managed Build Settings provider.
Don't use it myself as I rarely use Managed Build Projects.

[Updated on: Thu, 23 September 2021 04:57]

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844748 is a reply to message #1844721]

Fri, 24 September 2021 03:38

Nicholas Hathaway

Messages: 4
Registered: September 2021

Junior Member

That is the odd part, SeekDeepPrograms/SeekDeepProgram/SeekDeepSetUp.hpp can be found within the paths in the include path list ( /Users/nick/hathaway/external/local/SeekDeep/develop/SeekDeep/include, the full path to it is /Users/nick/hathaway/external/local/SeekDeep/develop/SeekDeep/include/SeekDeepPrograms/SeekDeepProgram/SeekDeepSetUp.hpp). And it is found when the indexer indexes the header file and the include paths list are exactly the same within the indexer log for both the header and the cpp file but the indexer says it can't resolve it when indexing the cpp file but not the header file which I find odd.

Nick

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844754 is a reply to message #1844748]

Fri, 24 September 2021 06:36

David Vavra

Messages: 1427
Registered: October 2012

Senior Member

Not strange at all.
Again, the include paths given to the compiler are not used by the Indexer.
Those are only used when creating Makefiles.
You have to tell the Indexer as well.

The Indexer ONLY uses the paths found in
Project --> Properties --> C/C++ General --> Preprocessor Include Paths, Macros etc. --> Entries tab

Many projects don't create makefiles. Some don't even use them.
Whatever the reason for the design decision, it's been like this for years.

You could request an enhancement (using bugzilla)
but I understand interest in maintaining the Indexer has waned.
I could be wrong about that.
OTOH: perhaps you might volunteer?

Not sure what you mean by it found it at one time. Both the .hpp and .cpp logs have:

Unresolved inclusion: <SeekDeepPrograms/SeekDeepProgram/SeekDeepSetUp.hpp> in file:
 /Users/nick/hathaway/external/build/pathweaver/develop/pathweaver/src/PathWeaver
/PostWeavingUtils/GatheringUtils.hpp

I see you didn't create a User Entry.
Here's what a typical User Entry looks like in the parser log:

Local Include Search Path:
   /opt/farAndAway/includes

You have these options:

repeat the paths for the Indexer as I've described
Use Paths and Symbols instead -- it's meant to solve the telling both problem
Build then let the GCC CDT Build Output Parser discover them

[Updated on: Fri, 24 September 2021 09:50]

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844798 is a reply to message #1844693]

Sun, 26 September 2021 03:06

Nicholas Hathaway

Messages: 4
Registered: September 2021

Junior Member

Sorry, I didn't realize I uploaded the wrong log file for the header file, here's the header where the indexer is able to discover the needed paths etc and all symbols/headers are resolved. I have re-uploaded the cpp parser log file re-created right now for completeness' sake, I haven't made any changes yet.

I've used eclipse CDT for years and in the past the parser was always able to determine the headers to parse after building. I don't pretend to understand quite what is happening underneath but in the past, after I compile a codebase the include paths get added to ".metadata/.plugins/org.eclipse.cdt.core/*.language.settings.xml" files and when I re-run the indexer it's able to resolve paths etc and this was able to work without needing to add anything to Project --> Properties --> C/C++ General --> Preprocessor Include Paths, Macros etc. --> Entries tab.

And the indexer is currently working for several of my codebases (by compiling it in eclipse to let CDT auto determine the include paths and then running Project --> Indexer --> Freshen All Files ) and it only stopped working recently but only for specific code bases but nothing has changed in those projects recently so I'm not sure what changed if it was something on my system or something else.

Nick

Attachment: GatheringUtils_hpp_parser_log.log
(Size: 588.20KB, Downloaded 30 times)
Attachment: GatheringUtils_cpp_parser_log.log
(Size: 104.38KB, Downloaded 31 times)

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844801 is a reply to message #1844798]

Sun, 26 September 2021 05:14

David Vavra

Messages: 1427
Registered: October 2012

Senior Member

Quote:

CDT for years and in the past the parser was always able to determine the headers to parse after building

I think it's the after building part that's important. The Build Output Parser will add
any paths found in the build log to the Indexer list.

If you are now saying, that's not working then look at the log parsing elements it is using. You
may have inadvertently changed them or the log output no longer allows using them.

You should be aware that CDT can parse a header that's opened for editing as long as it doesn't
refer to a header with a path that it doesn't have. The hpp log was generated from what
seems such a header.

The cpp log is still saying (among others):

Unresolved includes (from headers in index):
   Unresolved inclusion: SeekDeepPrograms/SeekDeepProgram/SeekDeepSetUp.hpp in file file:/Users/nick/newHathaway/external/build/PathWeaver/develop/PathWeaver/src/PathWeaver/PostWeavingUtils/GatheringUtils.hpp

So, you must in some way add the path where it can be found to the path list used by the Indexer.

[Updated on: Sun, 26 September 2021 05:24]

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844811 is a reply to message #1844693]

Sun, 26 September 2021 18:02

Nicholas Hathaway

Messages: 4
Registered: September 2021

Junior Member

And even after I add the paths manually to Project --> Properties --> C/C++ General --> Preprocessor Include Paths, Macros etc. --> Entries tab the parser is still not able to resolve the headers (attached new parser log after adding the paths).

I tested all older versions of CDT, the parser still works in the version from "CDT 10.1.0 for Eclipse 2020-12" and stopped working as of "CDT 10.2.0 for Eclipse 2021-03" for this project.

Is there a way for the parser to be more verbose or see if it's running into an issue somewhere along the line?

Attachment: GatheringUtils_cpp_parser_log_afterManualPathAdd.log
(Size: 107.97KB, Downloaded 29 times)

Report message to a moderator

Re: indexer not working on *.cpp files [message #1844813 is a reply to message #1844811]

Sun, 26 September 2021 23:41

David Vavra

Messages: 1427
Registered: October 2012

Senior Member

As far as I know, the parser log is the only way to debug the parser.
I've used both 2021-03 and 2021-06 without problems.
But that doesn't mean there aren't any.

One thing to check is that the paths you gave to the Indexer really contain the
files it's complaining about. Typos do happen. If they do contain the files, you
could submit a bug report but try to submit a minimal example that
demonstrates the problem. Sometimes trying to make a minimal example
gives clues to something you can fix.

Report message to a moderator

Re: indexer not working on *.cpp files [message #1847495 is a reply to message #1844813]

Fri, 29 October 2021 04:40

Mohith Manoj

Messages: 2
Registered: October 2021

Junior Member

I am suffering from the exact same issue. In my case the issue is more with header files. Index rebuilding solutions are totally useless. Indexer fails to pick up few of my own header files as well as some of system headers.

To troubleshoot the indexer I first generated the parse log file (sample attached ScrollWheel.log). On lines 11976 and 11977 you can see the indexer reporting unresolved files ParameterValue.h and VariableStepTable.h both of which are in my project and paths to both the files are known to the indexer (log file line number 60). I couldn't go any further than this for I don't know for what reason indexer is unable to resolve the header file even when it is in a known path.

The next step was to run eclipse in debug mode while adding options to get details on what the indexer is doing. I ran the following command in a terminal (Ubuntu).

./eclipse -debug .options

The option file is attached. Then I selected ScrollWheel.c and ScrollWheel.h in the project explorer and ran Index > Freshen All Files. Following is the output I get.

Indexer: start PDOMUpdateTask
Indexer: parsing /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: adding file:/mnt/win_d/Projects/ADS/TV1/LIN/SW/LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: processed /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h [97 ms]
Indexer: parsing /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: adding file:/mnt/win_d/Projects/ADS/TV1/LIN/SW/LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: processed /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h [47 ms]
Indexer: parsing /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: adding file:/mnt/win_d/Projects/ADS/TV1/LIN/SW/LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: processed /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h [95 ms]
Indexer: parsing /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.cpp
Indexer: adding file:/mnt/win_d/Projects/ADS/TV1/LIN/SW/LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.h
Indexer: adding file:/mnt/win_d/Projects/ADS/TV1/LIN/SW/LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.cpp
Indexer: processed /LinEmLibrary/library/Widgets/ParameterAdjustment/ScrollWheel.cpp [244 ms]
C/C++ Indexer: Project 'LinEmLibrary' (1 sources, 6 headers)
    Options: indexer='PDOMFastIndexer', parseAllFiles=false, unusedHeaders=skip, skipReferences=false, skipImplicitReferences=false, skipTypeReferences=false, skipMacroReferences=false.
    Database: 61857792 bytes
    Timings: 524 total, 280 parser, 20 resolution, 25 index update.
    Errors: 0 internal, 0 include, 0 scanner, 0 syntax errors.
    Names: 620 declarations, 1719 references, 0(0.00%) unresolved.
    Cache[1023MB]: 1571261 hits, 0(0.00%) misses.
Indexer: completed PDOMUpdateTask[524ms]

Here the indexer says it is adding and processing ScrollWheel.h and reports there are no unresolved Names.

Another important note is that the project was working fine (absolutely no issues with the Indexer) until I upgraded my system. I changed my drive from a 512G SSD to 1TB SSD. Also my project uses Log4CPlus and Google Protobuf, their headers are now installed in /usr/local/include. No change in OS (Ubuntu 20.04) or Eclipse (2021-09). The header file <log4cplus/loggingmacros.h> is no longer discovered by the indexer making all the Log4CPlus macros unresolved leaving a lot of red marks by CODAN. The auto complete is another part which seriously cripples writing code. Now every time I type in a '.' or '->' after an object the auto-complete takes a good amount of time (~30 seconds) before returning the list.

Attachment: ScrollWheel.log
(Size: 633.84KB, Downloaded 32 times)
Attachment: .options
(Size: 0.49KB, Downloaded 59 times)

Report message to a moderator

Previous Topic:	Unresolved inclusion of 'iostream' in a new CMake Hello World project
Next Topic:	"terminated" message

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Feb 04 03:46:52 GMT 2023

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter