Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => CodeCompletion redesign => Topic started by: ollydbg on February 10, 2012, 03:29:09 pm

Title: [RFA] patch to fix Bug #18483 Auto-completion of function pointers in a struct
Post by: ollydbg on February 10, 2012, 03:29:09 pm

I have the patch to fix this issue:
Auto-completion of function pointers in a structure (https://developer.berlios.de/bugs/?func=detailbug&bug_id=18483&group_id=5358)

Code

Index: parserthread.cpp
===================================================================
--- parserthread.cpp	(revision 7785)
+++ parserthread.cpp	(working copy)
@@ -1948,7 +1948,7 @@
     m_Tokenizer.SetState(oldState);
 }
 
-void ParserThread::HandleFunction(const wxString& name, bool isOperator)
+void ParserThread::HandleFunction(wxString& name, bool isOperator)
 {
     TRACE(_T("HandleFunction() : Adding function '")+name+_T("': m_Str='")+m_Str+_T("'"));
     int lineNr = m_Tokenizer.GetLineNumber();
@@ -2029,6 +2029,25 @@
                 break; // function decl
             else if (peek == ParserConsts::kw_const)
                 isConst = true;
+            else if (peek.GetChar(0)== ParserConsts::opbracket_chr)
+            {
+                //Here, we meet some kind of statement like: a function pointer declaration
+                //unsigned int (*func1)(int var1);
+                //now: peek = (int var1);
+                int pos = peek.find(ParserConsts::ptr);
+                if (pos != wxNOT_FOUND) //find *
+                {
+                    peek.Trim(true).RemoveLast();
+                    peek.Remove(0, pos+1);
+                    name = peek;
+                    peek = m_Tokenizer.PeekToken();
+                    //Thus, the peek should be ";"
+                    if( peek == ParserConsts::semicolon )
+                    {
+                        break; // function pointer declaration
+                    }
+                }
+            }
             else
                 break; // darned macros that do not end with a semicolon :/
 
Index: parserthread.h
===================================================================
--- parserthread.h	(revision 7785)
+++ parserthread.h	(working copy)
@@ -196,7 +196,7 @@
       * @param name function name
       * @param isOperator if true, means it is an operator overload function
       */
-    void HandleFunction(const wxString& name, bool isOperator = false);
+    void HandleFunction(wxString& name, bool isOperator = false);
 
     /** handle enum declaration */
     void HandleEnum();

So, I need your comments. :)

Title: Re: [RFA] patch to fix Bug #18483 Auto-completion of function pointers in a struct
Post by: oBFusCATed on February 10, 2012, 03:38:49 pm

Does the test suite passes, without failures?
Urhm, there is not test suite, then you're doomed. :)

Title: Re: [RFA] patch to fix Bug #18483 Auto-completion of function pointers in a struct
Post by: ollydbg on February 10, 2012, 03:45:12 pm

Quote from: oBFusCATed on February 10, 2012, 03:38:49 pm

Does the test suite passes, without failures?
Urhm, there is not test suite, then you're doomed. :)

I think the simplest test suite that we could do is to extend the parsertest project.

We feed some file(source file to it), and we check the log output (the tree list contains all the symbols), then we can see if it matches some standard log.

PS: I have no experiences on create any test suite project... :-[

Title: Re: [RFA] patch to fix Bug #18483 Auto-completion of function pointers in a struct
Post by: oBFusCATed on February 10, 2012, 03:55:17 pm

So now you can gain it, by making such a test suite project  :P

Title: Re: [RFA] patch to fix Bug #18483 Auto-completion of function pointers in a struct
Post by: MortenMacFly on February 10, 2012, 04:39:26 pm

Quote from: oBFusCATed on February 10, 2012, 03:38:49 pm

Does the test suite passes, without failures?
Urhm, there is not test suite, then you're doomed. :)

A simple "test suite" is to run let run CC through the C::B sources one time with and one time without the patch and inspect, how many tokens in how many files are found. if it's getting less -> something is seriously wrong.

However, generally obfuscated is right: we *need* unit testing here. But it won't be easy, as the parser has many options and you need actually to test against all their combinations. I've started with test cases under plugins\codecompletion\testing, though...