Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 333225 - Parser gives incorrect results when a header is included from two different source files with different #defines
Summary: Parser gives incorrect results when a header is included from two different s...
Status: CLOSED DUPLICATE of bug 197989
Alias: None
Product: CDT
Classification: Tools
Component: cdt-indexer (show other bugs)
Version: 8.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Markus Schorn CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-27 01:33 EST by Nathan Ridge CLA
Modified: 2010-12-28 03:48 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Ridge CLA 2010-12-27 01:33:36 EST
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.
Comment 1 Markus Schorn CLA 2010-12-27 04:17:03 EST

*** This bug has been marked as a duplicate of bug 197989 ***
Comment 2 Nathan Ridge CLA 2010-12-27 15:07:31 EST
(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.
Comment 3 Markus Schorn CLA 2010-12-28 03:48:17 EST
(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).