nearly finishing the current CodeCompletion structure wiki page

[ollydbg]

I'm reading the source code of code completion for about ten days. I think I nearly finished writing the wiki page of the current version.

Though I do not have the ability to greatly improve this plug-in, I just have some suggestions and maybe someone can quickly understand to improve.

First: Deal with macros.
The current design is that Tokenizer class use a function to check whether it specific keyword(or symbol) was meet, then it is quickly do the replacement. For example "_GLIBCXX_STD" should be replaced by "std".

I think this step should be put in the parserthread, in the DoParse() function. this will make the code runs a little faster, and maybe a "HandelMacor" function maybe add to parse these tokens. We can just learn from the CTAGS's method to treat macros.

Second:
Many code in the searchtree related code are not easy to understand because their variable names are not according with the coding style page in wiki page.

Third:
I found that the "using namespace XXX" was just skipped by the DoParse(), so, a lot of people were complaining this issue. I'm not sure how to deal with this problem, but maybe, the parser meet this keyword, the namespace should be exposed to the current scope, so that the codecompletion can search in that scope.

Any Comments are welcome, I'm just want to do something to improve Code Completion. Thanks for reading.

[Ceniza]

I haven't checked the wiki, but I was considering to have some sort of pluggable structures for each file. With this I mean that if you have B.cpp which includes B.h which includes A.h, each file would have its own parsed structure. B.cpp's structure would be connected to B.h's structure and B.h's structure to A.h's (in opposite order, actually). Such connection would create a new level of name resolution.

If the idea is to handle macros correctly, the structure should be able to provide the preprocessor tests that were met when it was parsed. It means that a single file could have multiple parsing structures depending on the macros that were defined before its inclusion. The most basic example is including a header file with guards twice. The first time it's included, its full contents will be parsed and available. The second time, all of it will be ignored. Therefore, one structure would have the condition XXX_INCLUDED not defined, and the other one XXX_INCLUDED defined.

Sorry if it's already in the wiki.

[ollydbg]

Yes, I agree with you.

There is another issue:
eg:
A.cpp include common.h
B.cpp include common.h

If A.cpp was parsed first, then, I think we could add common.h to the "parsed files tree", so, they won't be parsed in the B.cpp. ( I'm not sure if this has already implemented in current design , but the current one add all the token symbols to a global name tree )

[Ceniza]

Generating the final tree would be a little bit tricky. It would basically be all the names seen from the leaves of the parsed tree without duplicates.

Also, the idea of the parsed structures would be to make them re-usable. When a header file changes, all its children would most likely need to be re-parsed, except if the important bits of it did not change (in other words, the changes made to the header file do not invalidate the children's parsed structure).