Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329653 - Incremental index update causes a name resolution problem
Summary: Incremental index update causes a name resolution problem
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 8.0   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-08 01:09 EST by Sergey Prigogin CLA
Modified: 2020-09-04 15:19 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Prigogin CLA 2010-11-08 01:09:13 EST
To reproduce create a project with two files:

test.h
------
template <typename T>
struct C {
    void m(const T& p);
};

//namespace {

struct A {
    A() {}
};

//}

test.cc
-------
#include "test.h"

void test() {
    C<A> c;
    A a;
    c.m(a);
}

1. Rebuild the index. All symbols are resolved.
2. Uncomment the two commented out lines in test.h -- 'm' in test.cc becomes unresolved.
3. Rebuild the index -- 'm' is resolved again.
Comment 1 Markus Schorn CLA 2010-11-11 08:21:14 EST
I understand why that happens:
* We have two different bindings for 'struct A' depending on whether it is
  enclosed by an unnamed namespace or not.
* The instance C<A> is found via string representation (ASTTypeUtil) of its
  argument. The string representation does not distinguish between the two
  bindings.

A potential way to fix that:
We could move the concept of a file-local binding from IIndexBinding to IBinding. With that it can become part of the type signature.
Comment 2 Sergey Prigogin CLA 2010-11-11 15:37:12 EST
(In reply to comment #1)

It seems that the logic in ASTTypeUtil.appendNameCheckAnonymous is problematic since it doesn't distinguish between an anonymous namespace and its container namespace. We could potentially represent an anonymous namespace by a special string pattern containing the name of the file where the namespace is defined, for example {filename}. During name lookup we can match against all anonymous workspaces that are defined in directly or indirectly included files.
Comment 3 Sergey Prigogin CLA 2010-11-12 00:19:48 EST
(In reply to comment #2)
The approach described in comment #2 won't work in a situation like:

header1.h
---------
namespace {
class A {};
}

header2.h
---------
namespace {
A* a;
}

source.cc
---------
#include "header1.h"
#include "header2.h"

a = new A;

It looks like there is no alternative to the solution based on file-local bindings.