New code completion remarks/issues

[oBFusCATed]

Works fine here (debian 64-bit).

Both work (the completion and the calltip problems)?

[Jenna]

Works fine here (debian 64-bit).

Both work (the completion and the calltip problems)?

No only the completion and the tooltip for method.

[oBFusCATed]

Another bug, this time 100% reproducible:



Steps:
1. Create console project
2. Remove the auto generated code
3. Paste the code below:

Code Select Expand



struct TestStruct
{
    int a;

    int Test()
    {
        int test_1, test_2;
        tes
    }
};


4. Hit ctrl + space at "tes" line
5. Type t_ and repeat step 4. ... works as expected.

Tested on gentoo amd64 + cb 6112 debugger branch

[ollydbg]

Another bug, this time 100% reproducible:

Ok, I just do more test, for example, if you paste these code to your main.cpp.
Test Code one:

Code Select Expand


struct TestStruct
{
   int test_3;

   int Test()
   {
       int test_1, test_2;
       te
   }
};

Then you get the auto-completion list is:(see the screen shot as attachment 1)

Code Select Expand

template
Test
test_3

These Code two:

Code Select Expand

struct TestStruct
{
   int test_3;

   int Test()
   {
       int test_1, test_2;
       test_
   }
};
Then you will get only "test_3" in auto-completion list.(see attachment2)

These code three:

Code Select Expand

struct TestStruct
{
   int aaaaa;

   int Test()
   {
       int test_1, test_2;
       test_
   }
};

Now, it can autocomplete both "test_1" and "test_3". see the screen shot of attachment 3.




[attachment deleted by admin]

[ollydbg]

Let me explain why this bug happened.
It is related to the "initial search scope" in the CC's source code of AI() function.

Code Select Expand

// Start an Artificial Intelligence (!) sequence to gather all the matching tokens..
// The actual AI is in FindAIMatches() below...
size_t NativeParser::AI(TokenIdxSet& result,
                       cbEditor* editor,
                       const wxString& lineText,
                       bool noPartialMatch,
                       bool caseSensitive,
                       TokenIdxSet* search_scope,
                       int caretPos)
{
......
......



   if (result.size()<1) // found nothing in the search_scope, add global namespace
   {
       if (s_DebugSmartSense)
           Manager::Get()->GetLogManager()->DebugLog(F(_T("AI() result is zero. Adding global namespace.")));

       search_scope->insert(-1);
       FindAIMatches(components, result, -1, noPartialMatch, caseSensitive, true, 0xffff, search_scope);
   }

......



In the AI function, we firstly collect the "initial search scope", then do the recursive matching stage. I have already written some steps in the wiki, you can see here: 5 Automatic Code Completion, so, the "global namespace scope" is not added by default.( if I can remember, in a earlier revision, when we were collecting initial search scopes", global namespace is always added)

You can see the "if" condition.

For example, when we do the AI function in the code below:

Code Select Expand

struct TestStruct
{
   int test_3;

   int Test()
   {
       int test_1, test_2;
       te
   }
};

We firstly add the initial scope is "struct TestStruct", then do the AIMatch routing in this scope. Too bad that when the "local parser" parsing the local statement, both "test_1" and "test_2" will added to the "global scope namespace":

Code Select Expand

{
       int test_1, test_2;
       te
   }

So, when we do a AIMatch in the "strct TestStruct", we find we get the two matches: "Test()" and the member variable "test_3". At this time, we have already get the matching result size >1, so, due to the if condition, global namespace is not searched any more.

Solution:

We can have two solutions:
One: we can force to add the "global search scope" to the initial search, so that we can get the right matching result. the Pros is it is quite simple, the cons is that you will loose the performance and cause other issue.

For example:

Code Select Expand


int abcd;

int main()
{
   int abcd;
  ab
}


Here, both global variable and auto variable name will be prompted. In CB forum, some people just suggest the "auto variable" in the function body.

Two:
We don't need to add the global namespace in the initial search scope.
When the "local parser" parse the function body, the "auto variable" added as the children of the function body.

For example:

Code Select Expand

struct TestStruct
{
   int test_3;

   int Test()
   {
       int test_1, test_2;
       te
   }
};
This time, the initial search scope should be: "struct TestStruct" and the "Test()".
So, when we do an AIMatch under "TestStruct" scope, we get the "test_3" and "Test()" matches.
Also, when we do an AIMatch under "Test()", we get the "test_1" and "test_2" matches.
So, we get the expected prompted list.

I have tried to using this method, but I didn't get success, because, when a parserthread attached with a "local body" is initialed, the defualt m_Parent Token is always the "global namespace", so the "test_2" and "test_1" will always be added to the "global namespace".

If we can supply a way that we can "set" m_Parent pointer to "Test() Token", we can totally solved this problem.

[oBFusCATed]

We firstly add the initial scope is "struct TestStruct", then do the AIMatch routing in this scope. Too bad that when the "local parser" parsing the local statement, both "test_1" and "test_2" will added to the "global scope namespace":

Code Select Expand

{
       int test_1, test_2;
       te
   }

So, when we do a AIMatch in the "strct TestStruct", we find we get the two matches: "Test()" and the member variable "test_3". At this time, we have already get the matching result size >1, so, due to the if condition, global namespace is not searched any more.

So, this is a parser bug? Can it be fixed easily?

[blueshake]

It is not a bug.it can be fixed easily.

[damur]

Hi!

I tried to use wxWidgets in Codeblocks, but Code Completion does not work correctly. And I think it's because of an #elif directive. Try this:

Code Select Expand

#define CONDITION

#if defined(SOMETHING)
    #include "something.h"
#elif defined(CONDITION)
    #include "class1.h"
#endif


int main()
{
    return 0;
}
class1.h is a file which is not part of your project (because else it would be parsed either way). So the file class1.h doesn't get parsed.
Interesting: replace "something.h" with "class1.h" and class1.h gets parsed, although SOMETHING is not defined.

Directives like this are used in most header files of wx base classes, for example "wx/button.h"

I'm using ubuntu9.10 and codeblocks SVN 6088. I tried also the 8.02 stable release, but it had the same bug.

[blueshake]

it is not a bug.it is just not implemented yet.Be patient! Ollydbg had done a little work.it will be solved soon.

[ollydbg]

It is not a bug.it can be fixed easily.

@oBFusCATed
This is fixed in blueshakes this post: new cc search implemention.

[oBFusCATed]

OK, Might test it...

[ollydbg]

OK, Might test it...

In fact, only one statement do the hack:

Code Select Expand

search_scope->insert(-1);//alwayser search the global scope.