Bugzilla – Full Text Bug Listing
| Summary: | Indexer loses symbols from included header files | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Andrew Gvozdev <angvoz.dev> | ||||||||||||||
| Component: | cdt-indexer | Assignee: | Project Inbox <cdt-indexer-inbox> | ||||||||||||||
| Status: | RESOLVED INVALID | QA Contact: | Markus Schorn <mschorn.eclipse> | ||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | P3 | CC: | aleherb+eclipse, cdtdoug, malaperle, mao, mober.at+eclipse, yevshif, zeratul976 | ||||||||||||||
| Version: | 8.1.0 | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | All | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Andrew Gvozdev
Please provide me something to reproduce the problem. This could be a duplicate of bug 367753, it could also be a different issue. What is the exact version of CDT you are using? My most recent routine includes morning update of eclipse, and CDT is from nightly Juno builds. The exact version of CDT as of this report is 8.1.0.201201061108. I will try to isolate the cause as much as possible, but this is pretty big workspace and may take a while. This was going intermittently but for quite a while. I started noticing the issue I think since when Codan was introduced but it manifested itself not too often and mostly when I was too busy to hunt it down. Subjectively it got gradually worse - to the point I can reproduce it at will in my workspace. Created attachment 209235 [details]
screenshot of the problem
I stripped it down to the point where I have troubles to reproduce (it got intermittent). I still cannot provide example as the project is of our in-house project type.
But here is a screenshot illustration. Here in the code - "bool" from stdbool.h is used, which is a macro for C99 "_Bool" keyword.
Again, after reindexing it is happy with the code but after a few edits of foo.h and foo.c "bool" is not recognized as a macro anymore.
Do you have a project reference from bug-368045 to bar? Where does _ANSI_C_SOURCE get defined? It'd be interesting to look at the parser logs of foo.c, foo.h and stdbool.h, both when everything is working and when you see the error. Created attachment 209268 [details] parser logs (In reply to comment #5) > It'd be interesting to look at the parser logs of foo.c, foo.h and stdbool.h, > both when everything is working and when you see the error. FYI, I was not able reproduce today with the same project as on screenshot, but can with the previous strip version of the workspace, and it looks a little different today, foo.c is OK but foo.h is not. The content of files is the same. In one of variations, I also saw a message in parser log for foo.c that foo.h is unresolved and not indexed. > Do you have a project reference from bug-368045 to bar? No project reference, the include path is defined directly in Paths&Symbols as workspace path. > Where does _ANSI_C_SOURCE get defined? In standards.h. The weird thing is that the parser log for the file 'foo.h' uses c++ as language (which explains why the included file is not part of the index). I cannot reproduce this behavior. I will see if Toni can come up with an explanation for that. In any way, the file can be parsed in c++ without problems, and the log does not report any name resolution problem. While trying to reproduce the issue, I found out that when the file of the editor is added to the index (new indexer option), it sometimes uses the wrong language. I have fix for that. I am not sure whether this solves the problems, though. It would be valuable to get a parser log, that actually reports a name resolution problem. Created attachment 209324 [details]
parser logs for unresolved symbol situation
The attached logs are result of following:
1. Reindex project. All is well.
2. Modify foo.c. foo.c looks OK but foo.h does not recognize "bool" as macro anymore, instead highlights it as a keyword.
3. Modify foo.h. No visible change for foo.h but visually foo.c does not recognize bool neither as macro nor as keyword.
Created attachment 209338 [details]
parser log with language fix
I ran under debugger the latest master including commit b68ecdc716854333250c85d67533b84249b0b1dd and it did not resolve the issue.
Created attachment 209339 [details]
log
I also tried the project with my scanner discovery branch (sd90) where I have some handy logs. Here is the log with the stack traces from DescriptionScannerInfoProvider. BTW, how come indexer is asking for scanner info for *.h files? And for which language is that, obviously the answer would be different for C and C++?
(In reply to comment #10) > Created attachment 209339 [details] > log Please note that this is pure informational log to record the name of the resource passed to DescriptionScannerInfoProvider.getScannerInformation(IResource rc), there is no exception happening in the code. (In reply to comment #7) > The weird thing is that the parser log for the file 'foo.h' uses c++ as > language (which explains why the included file is not part of the index). I > cannot reproduce this behavior. I will see if Toni can come up with an > explanation for that. A .h file in a C++ project without context is always treated as C++ by default. The problem here seems to be that the the file is parsed without context although there should be one. I also tried to reproduce with the given project layout (both projects are C++, default indexer prefs), but without success. I do see the behavior reproducible as soon as I move foo.h into project bar. In this case foo.h and stdbool.h are not indexed, therefore opening foo.h in the editor will miss the defines from stdbool.h and navigation fails. Created attachment 209401 [details]
reproducible example
Not sure if it is reproducible reliable on another box, but I managed to reproduce with clean CDT installation + custom plugin stripped to the bone.
To make the best attempt I suggest to follow exactly:
- Import attached plugin to the workspace with CDT sources.
- Debug on attached sample workspace.
- First thing run indexer on project bug-368045. Note that in foo.c "bool" is correctly highlighted in gray as I set gray color for macros.
- Second add a white space in file foo.c and save. I am getting semantic error on "bool" right away.
Here is the indexer log I captured:
Indexer: start TriggerNotificationTask
Indexer: completed TriggerNotificationTask[0ms]
Indexer: start PDOMFastIndexerTask
C/C++ Indexer: Project 'bug-368045' (0 sources, 0 headers)
Options: indexer='PDOMFastIndexer', parseAllFiles=true, unusedHeaders=skip, skipReferences=false, skipImplicitReferences=false, skipTypeReferences=false, skipMacroReferences=false.
Database: 12288 bytes
Timings: 1086 total, 0 parser, 0 resolution, 0 index update.
Errors: 0 internal, 0 include, 0 scanner, 0 syntax errors.
Names: 0 declarations, 0 references, 0(0.00%) unresolved.
Cache[59MB]: 460 hits, 1(0.22%) misses.
Indexer: completed PDOMFastIndexerTask[1089ms]
Indexer: start PDOMRebuildTask
Indexer: parsing \bug-368045\src\foo\foo.c
Indexer: adding file:/C:/Andre/eclipse-CDT-HEAD/workspace-bug-368045/bar/headers/standards.h
Indexer: adding file:/C:/Andre/eclipse-CDT-HEAD/workspace-bug-368045/bar/headers/stdbool.h
Indexer: adding file:/C:/Andre/eclipse-CDT-HEAD/workspace-bug-368045/bug-368045/src/foo/foo.h
Indexer: adding file:/C:/Andre/eclipse-CDT-HEAD/workspace-bug-368045/bug-368045/src/foo/foo.c
!SESSION 2012-01-12 14:04:33.308 -----------------------------------------------
eclipse.buildId=I20111209-1447
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.sdk.ide
Command-line arguments: -product org.eclipse.sdk.ide -data C:\Andre\eclipse-CDT-HEAD\workspace-cdt-sd90/../workspace-bug-368045 -dev file:C:/Andre/eclipse-CDT-HEAD/workspace-cdt-sd90/.metadata/.plugins/org.eclipse.pde.core/workspace-bug-368045/dev.properties -os win32 -ws win32 -arch x86_64 -consoleLog -debug /Andre/eclipse-CDT-HEAD/indexer-debug.properties
!ENTRY org.eclipse.cdt.core 1 0 2012-01-12 14:05:07.725
!MESSAGE Indexed 'bug-368045' (1 sources, 3 headers) in 0.07 sec: 4 declarations; 42 references; 0 unresolved inclusions; 0 syntax errors; 0 unresolved names (0.00%)
C/C++ Indexer: Project 'bug-368045' (1 sources, 3 headers)
Options: indexer='PDOMFastIndexer', parseAllFiles=true, unusedHeaders=skip, skipReferences=false, skipImplicitReferences=false, skipTypeReferences=false, skipMacroReferences=false.
Database: 12288 bytes
Timings: 101 total, 21 parser, 0 resolution, 30 index update.
Errors: 0 internal, 0 include, 0 scanner, 0 syntax errors.
Names: 4 declarations, 42 references, 0(0.00%) unresolved.
Cache[59MB]: 2867 hits, 0(0.00%) misses.
Indexer: completed PDOMRebuildTask[111ms]
Indexer: start PDOMFastIndexerTask
Indexer: parsing \bug-368045\src\foo\foo.c
Indexer: adding file:/C:/Andre/eclipse-CDT-HEAD/workspace-bug-368045/bug-368045/src/foo/foo.c
C/C++ Indexer: Project 'bug-368045' (1 sources, 0 headers)
Options: indexer='PDOMFastIndexer', parseAllFiles=true, unusedHeaders=skip, skipReferences=false, skipImplicitReferences=false, skipTypeReferences=false, skipMacroReferences=false.
Database: 12288 bytes
Timings: 16 total, 0 parser, 0 resolution, 0 index update.
Errors: 0 internal, 0 include, 0 scanner, 0 syntax errors.
Names: 2 declarations, 1 references, 0(0.00%) unresolved.
Cache[59MB]: 686 hits, 0(0.00%) misses.
Indexer: completed PDOMFastIndexerTask[31ms]
Indexer: start PDOMFastIndexerTask
C/C++ Indexer: Project 'bug-368045' (0 sources, 2 headers)
Options: indexer='PDOMFastIndexer', parseAllFiles=true, unusedHeaders=skip, skipReferences=false, skipImplicitReferences=false, skipTypeReferences=false, skipMacroReferences=false.
Database: 12288 bytes
Timings: 0 total, 0 parser, 0 resolution, 0 index update.
Errors: 0 internal, 0 include, 0 scanner, 0 syntax errors.
Names: 0 declarations, 0 references, 0(0.00%) unresolved.
Cache[59MB]: 234 hits, 0(0.00%) misses.
Indexer: completed PDOMFastIndexerTask[0ms]
Not sure if it is relevant but one thing to note is that the plugin may disagree with MBS on some counts. In particular, it exhibits bug 340660 on some operations (but it does not appear in the log while reproducing this bug!). The plugin is under some suspicion as I tried but couldn't reproduce the behavior changing toolchain to one defined in CDT. (In reply to comment #13) > Created attachment 209401 [details] > reproducible example Markus, Tony, are you able to reproduce the issue with this example? (In reply to comment #15) > (In reply to comment #13) > > Created attachment 209401 [details] > > reproducible example > Markus, Tony, are you able to reproduce the issue with this example? No, I cannot. Our preference settings for the indexer may differ, though. What are the settings you are using? (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #13) > > > Created attachment 209401 [details] > > > reproducible example > > Markus, Tony, are you able to reproduce the issue with this example? > No, I cannot. Our preference settings for the indexer may differ, though. What > are the settings you are using? Indexer settings are all default. If you use attached workspace from the example that would be part of the workspace. (In reply to comment #17) > Indexer settings are all default. If you use attached workspace from the > example that would be part of the workspace. Of course! I did use the workspace, so I had the same settings. *** cdt git genie on behalf of Markus Schorn ***
Bug 368045: Choose correct language for indexing files opened in editor.
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b68ecdc716854333250c85d67533b84249b0b1dd
I see a commit from the CDT genie, but the issue is not marked as resolved ... so I'm wondering what is the status of this ? Andrew, is it still reproducable with latest master CDT ? To tell the truth I am not so sure right now. My working with C/C+ code is rather erratic these days and I update CDT often which triggers reindexing by itself. And it almost became a compulsion to reindex in case of problems. It was a pain to create reproducible case for this bug that worked kind of reliably even on my computer. I'll try to look into that again when I have more time. The commit might be related to comment#10 I think. Just filled Bug 423162 about indexer skipping some defines/declerations if file contains mixes dos/unix file endings. this is maybe related. Check by using File->ConverFileDelimiters->Windows or file->ConverFileDelimiters->Unix on affected files There's not much to do here without a reproductible testcase. If someone has one, please post it, and reopen the bug. |