New code completion remarks/issues

[MortenMacFly]

Notice that there is another call to HandlePreprocessorBlocks() in void ParserThread::SkipBlock() and ParserThread::HandleClass(EClassType ct).

I've added a test case for pre-processor handling to trunk. You'll realise that a lot things are not (yet) working (check the symbols browser). A major bug is handling of comments in preprocessors. :-(

[blueshake]

I've added a test case for pre-processor handling to trunk. You'll realise that a lot things are not (yet) working (check the symbols browser). A major bug is handling of comments in preprocessors. :-(

hello,morten
can you give me more informations about what is wrong with preprocessors,It seems work here.

[ollydbg]

Code

        else if (token==ParserConsts::hash)
        {
            token = m_Tokenizer.GetToken();
            if (token==ParserConsts::kw_include)
                HandleIncludes();
            else if (token==ParserConsts::kw_define)
                HandleDefines();
            else
                HandlePreprocessorBlocks(token);
            m_Str.Clear();
        }

Notice that there is another call to HandlePreprocessorBlocks() in void ParserThread::SkipBlock() and ParserThread::HandleClass(EClassType ct).

Yes, I also noticed that, this function in those places. But this is still nothing related to Tokenizer internals.

The Tokenizer class do quite simple things:

1, it skip the unnecessory preprocessor directives, such as:

Code

#pragma XXXX

2, return a correct token string

So, don't care about that.

[ollydbg]

Here is the final patch on Tokenizer, I just do a lot of re-factoring.

1, We don't need to check whether the CurrentCharr is a "C escaped character" if we are not in a C string.
2, I remove the if condition check at the end of the DoGetToken function. see Here and the following discussion
3, I add a Macroreplace function to deal with the new Macros in GCC 4.x. You need to add macro map, see Token replacement map
4, I add some comments of these function in the source file.

I have tested this patch for several days, and works fine.

Feed back and test case are all welcome!!!


[attachment deleted by admin]

[MortenMacFly]

Feed back and test case are all welcome!!!

I cannot apply this patch on trunk. Could you please provide a patch against (current) trunk using svn diff?

[ollydbg]

Feed back and test case are all welcome!!!

I cannot apply this patch on trunk. Could you please provide a patch against (current) trunk using svn diff?

Sorry, I don't know how to use svn diff. :oops:

So, I upload the source file for you, 




[attachment deleted by admin]

[MortenMacFly]

Sorry, I don't know how to use svn diff. :oops:

It's very easy:
- Install the SVN command lien client
- Modify the sources as needed
- Within the SVN controlled (sub-)directory, issue this command:
  svn diff > my_patch.patch
Done. :-)

So, I upload the source file for you, 

Works, thanks! I'll have a look... I have pending quite some patches now...

[ollydbg]

Sorry, I don't know how to use svn diff. :oops:

It's very easy:
- Install the SVN command lien client
- Modify the sources as needed
- Within the SVN controlled (sub-)directory, issue this command:
  svn diff > my_patch.patch
Done. :-)

Thanks for your help!!
So, here is the svn diff.


[attachment deleted by admin]

[oBFusCATed]

- Within the SVN controlled (sub-)directory, issue this command:
  svn diff > my_patch.patch
Done. :-)

Within the root of the svn tree is the better place to issue the command (also svn help diff for more info)

[MortenMacFly]

Within the root of the svn tree is the better place to issue the command (also svn help diff for more info)

Not for me, as I don't checkout the whole sources usually. So I need to manually change the patch quite often to remove e.g. the top-level "src" folder. Just do it as you like, I can handle both.

[blueshake]

patch for this http://forums.codeblocks.org/index.php/topic,11187.msg76954.html#msg76954

Code

Index: parserthread.cpp
===================================================================
--- parserthread.cpp	(revision 5872)
+++ parserthread.cpp	(working copy)
@@ -1719,7 +1719,7 @@
             {
                 // typedef void dMessageFunction (int errnum, const char *msg, va_list ap);
 
-                typ = _T("(*)");
+                //typ = _T("(*)");
                 // last component is already the name and this is the args
                 args = token;
             }
@@ -1757,7 +1757,7 @@
             ancestor << _T(' ');
         ancestor << token;
     }
-    ancestor << typ;
+    //ancestor << typ;
 
     // no return type
     m_Str.Clear();
@@ -1773,7 +1773,12 @@
             tdef->m_Type = ancestor;
         }
         else
-            tdef->m_ActualType = ancestor + args;
+        {
+            tdef->m_ActualType = ancestor;
+            tdef->m_Type = ancestor + typ;//+ args;
+            tdef->m_AncestorsString = ancestor;
+        }
+
     }
 }
 
@@ -1800,13 +1805,15 @@
                   current.c_str(),
                   m_Str.c_str(),
                   (m_pLastParent ? m_pLastParent->m_Name.c_str():_T("<no-parent>")));
-            Token* newToken = DoAddToken(tkClass, current, m_Tokenizer.GetLineNumber());
+            Token* newToken = DoAddToken(tkTypedef, current, m_Tokenizer.GetLineNumber());
             if (!newToken)
                 break;
             else
             {
                 wxString tempAncestor = ancestor;
                 newToken->m_AncestorsString = tempAncestor;
+                newToken->m_ActualType = tempAncestor;
+                newToken->m_Type = tempAncestor;
             }
         }
         else // unexpected
Index: token.cpp
===================================================================
--- token.cpp	(revision 5872)
+++ token.cpp	(working copy)
@@ -138,13 +138,11 @@
     wxString result;
     if (m_TokenKind == tkClass)
     {
-        result << _T("class ") << m_Name << _T(" {...}");
-        return result;
+        return result << _T("class ") << m_Name << _T(" {...}");
     }
     else if (m_TokenKind == tkNamespace)
     {
-        result << _T("namespace ") << m_Name << _T(" {...}");
-        return result;
+        return result << _T("namespace ") << m_Name << _T(" {...}");
     }
     else if (m_TokenKind == tkEnum)
     {
@@ -155,15 +153,18 @@
         result << _T("typedef") ;
         if (!m_Type.IsEmpty())
             result << _T(" ") << m_Type;
-        result << _T(" ") << m_Name;
-        return result;
+        if (result.find('*', true) != wxNOT_FOUND)
+        {
+            result.RemoveLast();
+            return result << m_Name << _T(")") <<  m_Args;
+        }
+        return result << _T(" ") << m_Name;
     }
     else if (m_TokenKind == tkPreprocessor)
     {
         result << _T("#define ") << m_Name << m_Args;
         if(!m_Type.IsEmpty())
-            result << _T(" ") << m_Type;
-        return result;
+        return result << _T(" ") << m_Type;
     }
     else
     {

[ollydbg]

here is the patch to solve parser the vector problem in this post and the following post:

http://forums.codeblocks.org/index.php/topic,11311.msg77512.html#msg77512

For example, the patch can parse this kind of statement:

Code

a  b::c d::e() {;};

Then, c is the return type.
e is the function name.


[attachment deleted by admin]

[ollydbg]

@blueshake:
Now, the whole test
in  cb_svn\src\plugins\codecompletion\testing\structs_typedefs.cpp
works!!! Thanks very much!!!

Also, a patch to fix a typo.

Code

Index: structs_typedefs.cpp
===================================================================
--- structs_typedefs.cpp	(revision 5873)
+++ structs_typedefs.cpp	(working copy)
@@ -6,7 +6,7 @@
   float y;
 };
 typedef struct _s t_s;
-typedef _s (*t_ptr)(int a, int b);
+typedef _s (*t_ptr_s)(int a, int b);
 
 typedef struct _s_inner
 {

[ollydbg]

I have find a bug, that will at least cause the CC to build browser tree twice when we just do a header/implementation file switch after you double click on a tree item. Also, rebuild a browser tree will cause a re-flash on the tree, and your lose the mouse position, this is really annoying!!!

Look at the code:

Code

void ClassBrowser::UpdateView()
{
    m_pActiveProject = 0;
    m_ActiveFilename.Clear();
    if (m_pParser && !Manager::IsAppShuttingDown())
    {
        m_pActiveProject = Manager::Get()->GetProjectManager()->GetActiveProject();
        cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
        if (ed)
        {
            //m_ActiveFilename = ed->GetFilename().BeforeLast(_T('.'));
            // the above line is a bug (see https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1559&group_id=5358)
            m_ActiveFilename = ed->GetFilename().AfterLast(wxFILE_SEP_PATH);
            if (m_ActiveFilename.Find(_T('.')) != wxNOT_FOUND)
            {
                m_ActiveFilename = ed->GetFilename().BeforeLast(wxFILE_SEP_PATH) + wxFILE_SEP_PATH + m_ActiveFilename.BeforeLast(_T('.'));
                m_ActiveFilename.Append(_T('.'));
            }
            else
                m_ActiveFilename = ed->GetFilename();
        }

        BuildTree();

        wxSplitterWindow* splitter = XRCCTRL(*this, "splitterWin", wxSplitterWindow);
        if (m_pParser->ClassBrowserOptions().treeMembers)
        {
            splitter->SplitHorizontally(m_Tree, m_TreeBottom);
            m_TreeBottom->Show(true);
        }
        else
        {
            splitter->Unsplit();
            m_TreeBottom->Show(false);
        }

    }
    else
        m_Tree->DeleteAllItems();
}

You can see:

Every time, this function is called, the m_ActiveFilename firstly be cleared, then a new m_ActiveFilename value was generated, and the tree was rebuild.

But how do we generate the m_ActiveFilename ?

For example, your active editor was :  "C:\BBB\AAA.cpp", at this time, the m_ActiveFilename was "C:\BBB\AAA.", If you double click on the browser tree item to swap the file, and the caret jump to "C:\BBB\AAA.h", the m_ActiveFilename is still "C:\BBB\AAA.".

At this time, we don't need to rebuild the tree again.

Any comments???

[blueshake]

At this time, we don't need to rebuild the tree again.

hi,ollydbg:
The contexts in C:\BBB\AAA.cpp are different from C:\BBB\AAA.h,why we don't need to rebuild the tree again?