try to solve the "typedef" problem.

[ollydbg]

Hi, everyone, I found many complaints about parsing typedef problem exists in the current design.
See the thread:
http://forums.codeblocks.org/index.php/topic,10240.msg70846.html#msg70846
Also, there are many thread talking about this.

I exam the code, and try to solve this problem. The problem comes from these code snippet around line 1474 in parsethread.cpp

Code

        else if (token == ParserConsts::kw_class ||
            token == ParserConsts::kw_struct)
        {
            // "typedef struct|class"
            m_LastUnnamedTokenName = peek;
            Manager::Get()->GetLogManager()->DebugLog(F(_("before class m_LastUnnamedTokenName'%s'"), m_LastUnnamedTokenName.c_str()));

            HandleClass(token == ParserConsts::kw_class);
            token = m_LastUnnamedTokenName;
            Manager::Get()->GetLogManager()->DebugLog(F(_("after class m_LastUnnamedTokenName'%s'"), m_LastUnnamedTokenName.c_str()));

        }

I add a logout to check the "m_LastUnnamedTokenName" value.
I found that the "m_LastUnnamedTokenName" will always get a empty string whether it is parsing a named structure or unnamed structure after calling the function HandleClass.

So, this is the sample code

Code

typedef class Ancestor{
    public:
    int m_aaaa;
    int m_bbbb;
} Parent;


int main()
{
    Parent obj;
    obj.
    //obj. //Show nothing! works badly.

    return 0;
}

To solve this, I just add one statement around line 1236 in the function HandleClass().

Code

                DoParse();

                m_pLastParent = lastParent;
                m_LastScope = lastScope;
                m_LastUnnamedTokenName = current; // Add this statement

So, it can parse correctly. see the screen shot below.






[attachment deleted by admin]

[MortenMacFly]

...Sorry, but I can't find the line/statements you refer to.

Do you have this patch:
http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2566&group_id=5358
applied? Could you post the exact position e.g. in reference to the SVN trunk code?

[ollydbg]

I haven't apply the patch:
http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2566&group_id=5358

Here is my patch as an attachment.

by the way: I add a marco to enable "Parser debug output", and it is still strange that this file will be parsed twice. This the debug output if I define "#define PARSER_DEBUG_OUTPUT 1"

Code

Passing list of files to parse
	DoParse Loop:m_Str='', token='typedef'
Before HandleClass m_LastUnnamedTokenName=''
	DoParse Loop:m_Str='', token='public'
	DoParse Loop:m_Str='public ', token=':'
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int ', token='m_aaaa'
	DoParse Loop:m_Str='int', token=';'
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int ', token='m_bbbb'
	DoParse Loop:m_Str='int', token=';'
	DoParse Loop:m_Str='', token='}'
After HandleClass m_LastUnnamedTokenName='Ancestor'
Adding typedef: name='Parent', ancestor='Ancestor'
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int ', token='*'
	DoParse Loop:m_Str='int * ', token='func'
Adding function 'func': m_Str='int * '
ParserThread::HandleFunction: name='func', args='(int)', peek='{'
Add token name='func', args='(int)', return type='int * '
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int(void)', token='main'
Adding function 'main': m_Str='int(void)'
ParserThread::HandleFunction: name='main', args='()', peek='{'
Add token name='main', args='()', return type='int(void)'
Starting batch parsing
	DoParse Loop:m_Str='', token='typedef'
Before HandleClass m_LastUnnamedTokenName=''
	DoParse Loop:m_Str='', token='public'
	DoParse Loop:m_Str='public ', token=':'
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int ', token='m_aaaa'
	DoParse Loop:m_Str='int', token=';'
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int ', token='m_bbbb'
	DoParse Loop:m_Str='int', token=';'
	DoParse Loop:m_Str='', token='}'
After HandleClass m_LastUnnamedTokenName='Ancestor'
Adding typedef: name='Parent', ancestor='Ancestor'
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int ', token='*'
	DoParse Loop:m_Str='int * ', token='func'
Adding function 'func': m_Str='int * '
ParserThread::HandleFunction: name='func', args='(int)', peek='{'
Add token name='func', args='(int)', return type='int * '
	DoParse Loop:m_Str='', token='int'
	DoParse Loop:m_Str='int(void)', token='main'
Adding function 'main': m_Str='int(void)'
ParserThread::HandleFunction: name='main', args='()', peek='{'
Add token name='main', args='()', return type='int(void)'

[attachment deleted by admin]

[pingf]

 THX,  It really works!
However ,it can't find the struct such as OPENFILENAME... :?

[ollydbg]

THX,  It really works!
However ,it can't find the struct such as OPENFILENAME... :?

How does OPENFILENAME defined? Where can I find these code for testing?

[pingf]

typedef struct tagOFNA {
   DWORD        lStructSize;
   HWND         hwndOwner;
   HINSTANCE    hInstance;
   LPCSTR       lpstrFilter;
   LPSTR        lpstrCustomFilter;
   DWORD        nMaxCustFilter;
   DWORD        nFilterIndex;
   LPSTR        lpstrFile;
   DWORD        nMaxFile;
   LPSTR        lpstrFileTitle;
   DWORD        nMaxFileTitle;
   LPCSTR       lpstrInitialDir;
   LPCSTR       lpstrTitle;
   DWORD        Flags;
   WORD         nFileOffset;
   WORD         nFileExtension;
   LPCSTR       lpstrDefExt;
   LPARAM       lCustData;
   LPOFNHOOKPROC lpfnHook;
   LPCSTR       lpTemplateName;
#ifdef _MAC
   LPEDITMENU   lpEditInfo;
   LPCSTR       lpstrPrompt;
#endif
} OPENFILENAMEA, *LPOPENFILENAMEA;

.......
.......

typedef OPENFILENAMEA OPENFILENAME;
.......
.......


vc+visual assist find it correctley!

for more , you can search the msdn.

[pingf]

still ,
CB can not find the OPENFILENAME automatically,
but if this struct is defined by me,
it works correctly!

[MortenMacFly]

CB can not find the OPENFILENAME automatically,

Check your project settings related to CC and add the folders as needed.

[ollydbg]

A little test source.

Code

typedef class Ancestor{
    public:
    int m_aaaa;
    int m_bbbb;
} Parent, pPointer;

int main()
{
    Parent obj;
    obj.             //can't works
    return 0;
}

At this time, CC can't works. I just add ,pPointer after Parent. It is not due to the path setting, but caused by the CC's parser.


Another issue:

Code

typedef OPENFILENAMEA OPENFILENAME;

The statement above will not regard OPENFILENAME as a derived class from OPENFILENAMEA, so, when you write.

Code

OPENFILENAME obj;
obj.  //CC can't work here

This was my opinion after reading the current CC's related sources.