Author Topic: New code completion remarks/issues  (Read 211987 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: New code completion remarks/issues
« Reply #195 on: October 20, 2009, 05:33:00 pm »
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. :-(
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: New code completion remarks/issues
« Reply #196 on: October 21, 2009, 02:52:52 am »
Quote
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.
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #197 on: October 21, 2009, 03:01:55 am »
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. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #198 on: October 21, 2009, 03:52:44 am »
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. :D

Feed back and test case are all welcome!!! :D


[attachment deleted by admin]
« Last Edit: October 21, 2009, 08:29:33 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: New code completion remarks/issues
« Reply #199 on: October 21, 2009, 09:16:58 am »
Feed back and test case are all welcome!!! :D
I cannot apply this patch on trunk. Could you please provide a patch against (current) trunk using svn diff?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #200 on: October 21, 2009, 10:03:55 am »
Feed back and test case are all welcome!!! :D
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,  :D




[attachment deleted by admin]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: New code completion remarks/issues
« Reply #201 on: October 21, 2009, 10:13:50 am »
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,  :D
Works, thanks! I'll have a look... I have pending quite some patches now...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #202 on: October 21, 2009, 10:28:12 am »
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]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: New code completion remarks/issues
« Reply #203 on: October 21, 2009, 10:50:34 am »
- 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)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: New code completion remarks/issues
« Reply #204 on: October 21, 2009, 11:10:47 am »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: New code completion remarks/issues
« Reply #205 on: October 21, 2009, 03:16:04 pm »
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
     {
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #206 on: October 22, 2009, 09:03:26 am »
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]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #207 on: October 22, 2009, 10:42:55 am »
@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
 {
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #208 on: October 30, 2009, 04:15:54 pm »
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???
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: New code completion remarks/issues
« Reply #209 on: October 31, 2009, 05:21:59 am »
Quote
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?
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?