Community
Participate
Working Groups
Here is the test code, consisting of three files: define.hpp: #ifdef MY_DEFINE #define CALL_F() f(0) #else #define CALL_F() f() #endif define1.cpp: #define MY_DEFINE #include "define.hpp" struct S { void foo(); }; S f(int); void g() { CALL_F().foo(); } define2.cpp: #include "define.hpp" struct T { void bar(); }; T f(); void g() { CALL_F().bar(); // ERROR HERE } These files compile just fine with gcc, but the CDT parser gives an error define.hpp on the line CALL_F().bar(): "bar: method could not be resolved" Hovering over CALL_F() in define2.cpp to see the macro expansion, it is "f(0)", suggesting that the parser thinks MY_DEFINE is defined, even though it is not in define2.cpp. Notice that it is the call to bar(), and not the call to CALL_F() (which expands to f(0)) which is giving the error, suggesting that the parser figures that the f being called is the f in define1.cpp, which returns S, which does not have a bar() method (indeed, if I add a bar() method to S in define1.cpp, the error goes away!!). This suggests that there are (at least) two underlying problems: 1. The CALL_F() in define2.cpp expands to f(0) and not f(), suggesting that the parser thinks MY_DEFINE is defined in define2.cpp when it is not. 2. Having expanded CALL_F() to f(0) in define2.cpp, the parser decides that the f being called is the one in define1.cpp. This is wrong, since the f in define1.cpp is not in scope in define2.cpp.
*** This bug has been marked as a duplicate of bug 197989 ***
(In reply to comment #1) > *** This bug has been marked as a duplicate of bug 197989 *** Bug 197989 talks about a deficiency in the fast indexer; however, I am experiencing this problem with the full indexer.
(In reply to comment #2) > (In reply to comment #1) > > *** This bug has been marked as a duplicate of bug 197989 *** > Bug 197989 talks about a deficiency in the fast indexer; however, I am > experiencing this problem with the full indexer. Besides the fact that the full indexer is no longer part of CDT, it would not solve the problem. The editor that shows the error, parses its content like the fast indexer does. Parsing the included headers would consume too much time. The underlying issue is, that the index maintains a single version of any file, only. This could be fixed with reasonable effort (see bug 197989).