|
|
|
|
|
Re: CDT 8/Indigo: Editor erroneously marks some symbols as unresolved [message #691458 is a reply to message #691147] |
Fri, 01 July 2011 13:49 |
Andrew Gvozdev Messages: 257 Registered: July 2009 |
Senior Member |
|
|
eight wrote on Thu, 30 June 2011 16:03HI Andrew,
I did try to switch off some of the indexers, however, there was no direct correspondence between the error description and the indexer description, therefore I wasn't sure which one to turn off, and did not want to turn the wrong one, assuming that it is better to have false negatives than having false positives.
--8
To be clear (as hordes of people read this), first you should make sure that all includes are resolved and there is no "unresolved inclusion" messages. If there are - you should add proper include paths in project properties->"C/C++ General"->"Paths and Symbols". I believe you've done that. If you still have bogus errors represented by "bug" icon, those are configurable on Window->Preferences->"C/C++"->"Code Analysis" page. The problem "Name" should match the error description you are seeing. Use "Customize Selected" button and "Scope" tab lets define "Exclusion patterns".
Andrew
|
|
|
|
|
|
Re: CDT 8/Indigo: Editor erroneously marks some symbols as unresolved [message #693711 is a reply to message #690450] |
Thu, 07 July 2011 04:09 |
eight Messages: 27 Registered: June 2011 |
Junior Member |
|
|
I found one explanation/scenario reproducible. Let's say there are two projects master and slave. By itself, slave can compile and build without error markers. However when it is build due to a reference by a master, some of the includes are not resolved, as far as the master, not slave, is concerned. In this context these non-resolved dependencies will be marked as errors in the slave project. The include traversal still works, however. This gives an impression to the developer that something is wrong with the IDE.
Rebuild the slave alone, and the error markers will be gone.
In other words, the error markers are context-dependent, while the inclusion traversal takes the best result of all available contexts. That's a theory.
My gut feeling is that the Eclipse CDT developers are not testing against this scenario.
Sometime, I notice that building the slave project triggers the build of the master, which masks the behaviour above (that is the errors still appear in the slave, even after it had been rebuilt).
--8
[Updated on: Thu, 07 July 2011 18:11] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04653 seconds