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