New code completion remarks/issues

[ollydbg]

Also, is it possible using the predefined macro name for function name?

Code Select Expand

__FUNCTION__ or

Code Select Expand

__PRETTY_FUNCTION__

since codeblocks is build under GCC.

[ollydbg]

here is the patch of using "TRACE" macro for tokenizer.cpp and parserthread.cpp.




[attachment deleted by admin]

[ollydbg]

patch for nativeparser.cpp


[attachment deleted by admin]

[MortenMacFly]

I believe the std:: int the actualtype cause it.

Guys, I found the reason for that and it's not easily solvable.

std:: completion worked fine (and still works fine) with GCC3. It is broken with GCC4 and the reason is simple:
Take for example the file vector.tcc (which is the implementation of std::vector in your GCC folder).
In version 3 it was:

Code Select Expand


#ifndef _VECTOR_TCC
#define _VECTOR_TCC 1

namespace _GLIBCXX_STD
{
 // ...
} // namespace std

#endif /* _VECTOR_TCC */

As we replace "_GLIBCXX_STD" within the parser with "std", std::(vector) was easily resolvable. Now things have changed for GCC4, now the wrapper is as follows:

Code Select Expand


#ifndef _VECTOR_TCC
#define _VECTOR_TCC 1

_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)

 // ...

_GLIBCXX_END_NESTED_NAMESPACE

#endif /* _VECTOR_TCC */

As you see: This is done using a macro. As we don't have macro expansion it won't work with out implementation of CC anymore. So - this is not a bug in CC, "just" a missing feature and it happens now as we all just jumped to GCC4.

Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "}", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-) In addition the macros is not always like that and sometimes appears multiple times / is nested. So replacements have to be done carefully.

[ollydbg]

As we replace "_GLIBCXX_STD" within the parser with "std", std::(vector) was easily resolvable. Now things have changed for GCC4, now the wrapper is as follows:

Code Select Expand


#ifndef _VECTOR_TCC
#define _VECTOR_TCC 1

_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)

  // ...

_GLIBCXX_END_NESTED_NAMESPACE

#endif /* _VECTOR_TCC */

As you see: This is done using a macro. As we don't have macro expansion it won't work with out implementation of CC anymore. So - this is not a bug in CC, "just" a missing feature and it happens now as we all just jumped to GCC4.

Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "empty", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-)

For these kind of macros, we can learn from the Ctags.

See this post:

http://forums.next.codeblocks.org/index.php/topic,10827.msg74127.html#msg74127

We should expand the replacement method in tokenizer.cpp.

[MortenMacFly]

We should expand the replacement method in tokenizer.cpp.

No. This does not work, because:

Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "empty", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-)

[ollydbg]

We should expand the replacement method in tokenizer.cpp.

No. This does not work, because:

Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "empty", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-)

I mean, you can check the token == _GLIBCXX_BEGIN_NESTED_NAMESPACE, if it proves, the tokenizer can eat the following token which is ( "(std, _GLIBCXX_STD_D)"), or do anything you want.

So, what we need to do is "expand the replacement method", which means the tokenizer not only do the replacement, but also do "eat" the next token, or do something else

[MortenMacFly]

I mean, you can check the token == _GLIBCXX_BEGIN_NESTED_NAMESPACE, if it proves, the tokenizer can eat the following token which is ( "(std, _GLIBCXX_STD_D)"), or do anything you want.

OK - that might work, indeed and would probably be a feasible solution. But: This is very error prone, for sure. If you look deeper into the STL classes the macros contain macros in itself so the order of replacements matters!

However - I did a nasty hack so that std:: completion works again. I am replacing directly within the buffer before the Tokenizer starts any action. This proves that CC would still be able to do the right thing so it's not a bug.
Hence the cost for this is several calls to wxString::Replace which simply takes an awful lot of time. But it was what I could do quickly.

If anybody is interested in a patch, I can so so...?!

[ollydbg]

I mean, you can check the token == _GLIBCXX_BEGIN_NESTED_NAMESPACE, if it proves, the tokenizer can eat the following token which is ( "(std, _GLIBCXX_STD_D)"), or do anything you want.

OK - that might work, indeed and would probably be a feasible solution. But: This is very error prone, for sure. If you look deeper into the STL classes the macros contain macros in itself so the order of replacements matters!

However - I did a nasty hack so that std:: completion works again. I am replacing directly within the buffer before the Tokenizer starts any action. This proves that CC would still be able to do the right thing so it's not a bug.
Hence the cost for this is several calls to wxString::Replace which simply takes an awful lot of time. But it was what I could do quickly.

If anybody is interested in a patch, I can so so...?!

I really concern the performance of the parsing, if you do this "replacement" in every m_Buffer of Tokenizer.

[MortenMacFly]

If anybody is interested in a patch, I can so so...?!

Here it is btw...

Edit: Invalid now and not needed anymore, just uncomment the section in trunk.

[oBFusCATed]

I want to test it, but it failed to apply in the debugger branch...
Morten can you sync trunk and debugger branch?

[MortenMacFly]

Morten can you sync trunk and debugger branch?

Sure, but not today anymore.
Hence you can surely just checkout the CC plugin from trunk only and do a file comparision/sanc with the debugger branch yourself. The only method you need to take care about is SetSelectionVoid. That should be the only difference to trunk then.

[ollydbg]

Hi, here is the patch for tokenizer.cpp and tokenizer.h

I just change some variable name, such as

m_Str in DoGetToken() function changes to str.
Also, I add a function FixArgument to wrap a lot of operations.


[attachment deleted by admin]

[MortenMacFly]

Morten can you sync trunk and debugger branch?

Done. Patch is not needed anymore, just uncomment the section in question in the tokenizer.

[blueshake]

For the right valuetip on typedef.
patch:

Code Select Expand

Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 5852)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -1765,6 +1765,7 @@
         {
             tdef->m_AncestorsString = ancestor;
             tdef->m_ActualType = ancestor;
+            tdef->m_Type = ancestor;
         }
         else
             tdef->m_ActualType = ancestor + args;


[attachment deleted by admin]