News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

[RFA] patch to fix Bug #18483 Auto-completion of function pointers in a struct

Started by ollydbg, February 10, 2012, 03:29:09 PM

Previous topic - Next topic

ollydbg

I have the patch to fix this issue:
Auto-completion of function pointers in a structure

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. :)
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.

oBFusCATed

Does the test suite passes, without failures?
Urhm, there is not test suite, then you're doomed. :)
(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!]

ollydbg

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... :-[
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.

oBFusCATed

(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!]

MortenMacFly

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...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]