Confirmed.
The structure is basically as
follows:
/PROJECT/pkg1/subpkg1/subsubpkg1/src/x.cpp
/PROJECT/pkg1/subpkg1/subsubpkg1/h/x.h
For the test, only one open editor with
x.cpp.
Well, here is part of "reality":
/* Sourcefile:
vic_gridcode.cpp */
#include
"vic_gridcode.h"
Cvic_GridCodeObj::Cvic_GridCodeObj()
{
mVicSmObjPtr = NULL;
mVicSmDataPtr =
NULL;
...
Select
mVicSmObjPtr, "Open Call Hierarchy" --> Error "The file 'vic_gridcode.h' is
not included in the index..."
There is no warning
marker on the #include line, as the file is found and parsed.
Pressing F3 opens vic_gridcode.h in editor and jumps to
correct line
class Cvic_GridCodeObj : public CObjBase
{
...
private:
Cvic_stateMachine*
mVicSmObjPtr; // Pointer to fast vic
statemachine object
Cheers
Achim
Please confirm that you have 'x.cpp' in the editor while
message says 'x.h' is not in the index,
Markus.
Hello to
all,
we have a
strange problem with the function "Open Call Hierarchy" for class
member variables after upgrading from Ganymede to Galileo SR1 (yes,
I know, SR2 is out, but we are still on SR1).
Scenario: A file
x.cpp is open in the editor, I select a member variable
mval and choose "Open Call Hierarchy". The call hierarchy view
shows, and after some milliseconds, I get the message "The file 'x.h' is not
included in the index. For headers that are never included, or sources
that are not part of the build, consider selecting the preference 'index all
files'". No call graph is shown.
But that
header definitely is part of the index. I can see that it
gets added to the index when I turn on the CDT traces. And, using "Open
Declaration" does work, it correctly opens x.h and shows the correct line
where mval is defined.
Additionally,
trying to show the call hierarchy for a C++ method of the same class works
as expected. The error is only with member variables.
Before I add
this to Bugzilla, I need some assistance because: So far I was unable to
reproduce this with a small example project. I tried for hours
already.
The
problem only shows in our huge real-world project (but there
it shows very consistently). That project takes more than 50min. to
index, so it's not easy to handle - and absolutely impossible to attach
to a bug report. See the results in the trace
below.
To make things
worse, there are parts of the project where the call hierarchy does work
fine even for member variables. Up to now I can't see why some areas of the
code always fail with the Call Hierarchy, while others always succeed. I'm
quite confused.
C/C++
Indexer: Project 'XXX' (5963 sources, 8409 headers)
Options: indexer='PDOMFastIndexer', parseAllFiles=false, unusedHeaders=skip,
skipReferences=false, skipImplicitReferences=false,
skipTypeReferences=false, skipMacroReferences=false.
Database: 200904704 bytes
Timings: 3091514 total,
995236 parser, 122241 resolution, 461911 index update.
Errors: 0 internal, 960 include, 1920 scanner, 7588 syntax
errors.
Names: 780305 declarations, 4217017
references, 70729(1.40%) unresolved.
Cache[89mb]:
519133159 hits, 7708(0.00%) misses.
Indexer: completed
PDOMRebuildTask[3096407ms]
Yes, there are
quite a few errors during parsing, but with Eclipse 3.4/CDT 5.x the call
hierarchy does work with the exact same source files.
Do you have any
ideas how to track this down? Any special traces that I should enable? I
can't add a bug report without a reproducible example.
Thanks for any
help, I'm completely lost and frustrated at the moment!
-Achim