Bug 325296

Comment 1 John Liu 2010-09-14 17:03:25 EDT

Created attachment 178883 [details]
C++ project zip file

Comment 2 John Liu 2010-09-14 17:17:19 EDT

Some additional information found from my debugging so far. Hope it will help a bit.

1, The sequence of parsing files does matters, make sure a.C is parsed first to reproduce the problem. I have it parsed last at the beginning of my test and it worked file.

2, Seems like, the function "protected PDOMFile getLocalToFile(IBinding binding, PDOMBinding glob) throws CoreException" (line 940 of PDOMCPPLinkage) won't be able to return a PDOMFile for the binding of struct A in a.C.

Comment 3 Markus Schorn 2010-09-16 05:53:05 EDT

In general a class with the same name refers to the same type. This is certainly true for each translation-unit, but also a link-time (where types are only significant in terms of function signatures).

So in case all files are linked together classes with the same name refer to the same type. Even if they are not linked together it is likely that they refer
to the same type (with slightly different implementations for different platforms). In any way the parser does not have a way to determine whether two classes with the same name are supposed to refer to the same type or not. Therefore we cannot provide a solution that works correctly for every case.

The current situation is:
Classes with the same name are identified with each other. An exception is made, if the type is defined in a source file and no other file uses a forward declaration to potentially use the (otherwise hidden) class-type. This specific
implemenation was motivated by bug 262719.

It is a pretty high goal to come up with useful tooling for invalid code. Also,
support for code that is not linked together will always be limited.

Comment 4 John Liu 2010-09-16 11:05:39 EDT

(In reply to comment #3)
> In general a class with the same name refers to the same type. This is
> certainly true for each translation-unit, but also a link-time (where types are
> only significant in terms of function signatures).
> So in case all files are linked together classes with the same name refer to
> the same type. Even if they are not linked together it is likely that they
> refer
> to the same type (with slightly different implementations for different
> platforms). In any way the parser does not have a way to determine whether two
> classes with the same name are supposed to refer to the same type or not.
> Therefore we cannot provide a solution that works correctly for every case.
> The current situation is:
> Classes with the same name are identified with each other. An exception is
> made, if the type is defined in a source file and no other file uses a forward
> declaration to potentially use the (otherwise hidden) class-type. This specific
> implemenation was motivated by bug 262719.
> It is a pretty high goal to come up with useful tooling for invalid code. Also,
> support for code that is not linked together will always be limited.

Right, there is a name clash when a compiler links all of source files - I am a bit confused with Java here. 

This maybe a right behavior, like sturct A is declared in a.C, then the indexer looks for its definition globally and find A definitions from b.C and c.C at the end.

But should indexer find class definition for a struct declaration? I know struct is indeed a class in C++, but should indexer still need to differentiate them?

Comment 5 Markus Schorn 2010-09-16 12:24:09 EDT

(In reply to comment #4)
> ...
> But should indexer find class definition for a struct declaration? I know
> struct is indeed a class in C++, but should indexer still need to 
> differentiate them?
In C++, with the forward declaration 'struct S;' you can refer to the type defined with 'class S {}'. The following example compiles:

class C {
public:
  int a;
};

void test() {
  struct C c;
  c.a= 1;
}

Comment 6 John Liu 2010-09-16 14:13:14 EDT

(In reply to comment #5)
> (In reply to comment #4)
> > ...
> > But should indexer find class definition for a struct declaration? I know
> > struct is indeed a class in C++, but should indexer still need to 
> > differentiate them?
> In C++, with the forward declaration 'struct S;' you can refer to the type
> defined with 'class S {}'. The following example compiles:
> class C {
> public:
>   int a;
> };
> void test() {
>   struct C c;
>   c.a= 1;
> }

Ah I see, so a struct is really a class. 

OK I will close this bugzilla as invalid.
 
Thanks a lot, Markus for spending time in investigating it.