Some annoying symbols-browser issues

[Jenna]

One issue I get on windows xp and on my debian system (gcc 4.5 on windows amd 4.6 on linux) is, that neither the PARSER_START not the PARSER_END event is caught by the appropriate event-handlers.
Refreshing the symbols-browser tree manually works, switching between the View (e.g. Everything and workspace) works also.
The event is sent correctly if I debug C::B, but as I wrote it is never caught.

Another thing, is that switching between workspace- and project-view does not show all symbols. In both views I only get the symbols from the project, that was active when opening the workspace (two projects, one parser per project or one parser per workspace).

As third: I always see some boost-defines and most likely some of the other high-priority headers (former up-front) in the symbols-browser, even if I do not include these headers any of my projects.

[ollydbg]

One issue I get on windows xp and on my debian system (gcc 4.5 on windows amd 4.6 on linux) is, that neither the PARSER_START not the PARSER_END event is caught by the appropriate event-handlers.

I'm testing this issue on Windows XP and rev 7289.
It seems all the PARSER_START and PARSER_END works fine.
The flow is something like:(when a project is loaded)
1, send PARSER_START
2, NativeParser::OnParserStart() been called
3, CodeCompletion::OnParserStart() been called
4, send PARSER_END
5, NativeParser::OnParserEnd() been called
6, CodeCompletion::OnParserEnd() been called.

As third: I always see some boost-defines and most likely some of the other high-priority headers (former up-front) in the symbols-browser, even if I do not include these headers any of my projects.

The high-priority headers were predefined by Codecompletion plugin, and they were searched and parsed before parsing any actual files in your projects. This behavior is used to handle some predefined macro definition in those high-priority headers. So, even you did not include those files in your projects, they were still be parsed, thus this issue you complain happens.
I think you can simply change these high-priority headers in Codecompletions options dialog.

[Loaden]

As third: I always see some boost-defines and most likely some of the other high-priority headers (former up-front) in the symbols-browser, even if I do not include these headers any of my projects.

The high-priority headers were predefined by Codecompletion plugin, and they were searched and parsed before parsing any actual files in your projects. This behavior is used to handle some predefined macro definition in those high-priority headers. So, even you did not include those files in your projects, they were still be parsed, thus this issue you complain happens.
I think you can simply change these high-priority headers in Codecompletions options dialog.

Maybe we can put it into "Project > Properties > C/C++ Parser options".
So that each project can be set to different high-priority headers.

[MortenMacFly]

Maybe we can put it into "Project > Properties > C/C++ Parser options".
So that each project can be set to different high-priority headers.

But then, people won't do it and effectively loose this feature. I think it' OK to have them in one place and maybe spoil the symbol table with a little useless information. In the end it doesn't consume too much memory.

BTW: Jens, I cannot reproduce on Windows XP. Could you provide simple steps / a project to reproduce? Do you see in the debug log the message "NativeParser received parser end event" and "CodeCompletion received parser end event"? I see them whatever parsr configuration I use...?!

[Jenna]

@ollydbg:
I know how the event-handling should work, and the appropriate calls to PostParserEvent are made, but the events are never caught.
Here is the debug-log after creating a new console-project with the wizard, before creating I cleaned the log:

Code

4 user templates loaded
Project's base path: /tmp/test/
Project's common toplevel path: /tmp/test/
Caching GCC dir: /usr/include/c++/4.6
Caching GCC dir: /usr/include/c++/4.6/x86_64-linux-gnu
Caching GCC dir: /usr/include/c++/4.6/backward
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include-fixed
Caching GCC dir: /usr/include/x86_64-linux-gnu
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse with priority: '/usr/include/c++/4.6/cstddef'
Header to parse with priority: '/usr/include/boost/config.hpp'
Header to parse with priority: '/usr/include/boost/filesystem/config.hpp'
Add 3 priority parsing file(s) for project 'test'...
Added 1 file(s) for project 'test' to batch-parser...
Create new parser for project 'test'

Of course nothing happens in the symbols-browser, but after refreshing the tree, evrything is there.

@MortenMacFly:
I can not test on XP at the moment, not at work until next week (holidays  ), but will test it on win7 later.

About littering the symbols-browser with boost- (and other) defines:
it's a minor issue, but I would prefer to see only stuff, that is in the scope of my application.
Is there no information about the reachable header-files to filter these defines ?

By the way the autocompletion does not work for any defines after an #ifdef, but on a blank line.

[ollydbg]

@ollydbg:
I know how the event-handling should work, and the appropriate calls to PostParserEvent are made, but the events are never caught.
Here is the debug-log after creating a new console-project with the wizard, before creating I cleaned the log:

Code

4 user templates loaded
Project's base path: /tmp/test/
Project's common toplevel path: /tmp/test/
Caching GCC dir: /usr/include/c++/4.6
Caching GCC dir: /usr/include/c++/4.6/x86_64-linux-gnu
Caching GCC dir: /usr/include/c++/4.6/backward
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include-fixed
Caching GCC dir: /usr/include/x86_64-linux-gnu
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse with priority: '/usr/include/c++/4.6/cstddef'
Header to parse with priority: '/usr/include/boost/config.hpp'
Header to parse with priority: '/usr/include/boost/filesystem/config.hpp'
Add 3 priority parsing file(s) for project 'test'...
Added 1 file(s) for project 'test' to batch-parser...
Create new parser for project 'test'

I have the similar message under WinXP, but I just setting breakpoints on the event-handers, and every event-handler function will be reached.

BTW: Jens, I cannot reproduce on Windows XP. Could you provide simple steps / a project to reproduce? Do you see in the debug log the message "NativeParser received parser end event" and "CodeCompletion received parser end event"? I see them whatever parsr configuration I use...?!

@morten:
the strange thing is,  my log was quite similar with jens', and there is NO such log like:

Code

CodeCompletion received parser end event

But looking at the source code, it should be there( I can even reaching the breakpoint in that function body)

Code

oid CodeCompletion::OnParserEnd(wxCommandEvent& event)
{
    if (!Manager::IsAppShuttingDown())
        Manager::Get()->GetLogManager()->DebugLog(_("CodeCompletion received parser end event."));

    ParsingType type = static_cast<ParsingType>(event.GetInt());
    if (type == ptCreateParser)
    {
        if (   !m_SystemHeadersThread.empty()
            && !m_SystemHeadersThread.front()->IsRunning()
            && m_NativeParser.Done() )
        {
            m_SystemHeadersThread.front()->Run();
        }
    }

    cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (editor)
        ParseFunctionsAndFillToolbar(true);

    event.Skip();
}

Does it means the "DebugLog" function does not works correctly? or some messages were slip away???

[oBFusCATed]

Does it means the "DebugLog" function does not works correctly? or some messages were slip away???

I guess if it is called from a non-main-gui thread, a race condition is possible (wxGTK is almost single threaded lib) and skipped messages, too.

[ollydbg]

@all. sorry, I think I was making a mistake.

I'm seeing the debug-log from an very old nighty build rev 7075.

and the log message was added in rev 7273 by morten

mortenmacfly  2011-7-3 19:46:20             
* CC: show some more information to the user to hunt CC bugs
- CC: remove long-time obsolete functions to save a CC cache

So, That's my mistake, sorry for the noise.

And I have tested
1, loading a cbp project
2, using wizard to create a simple console project.

Both of them will show such "CodeCompletion received parser end event." kind message.

@jens:
did you use an old revision before rev 7273??

[Loaden]

Jens, are you using Debian Testing?

[Jenna]

Jens, are you using Debian Testing?

Unstable/experimental (with some libs of testing of course), with libgtk2.0 2.24.5-4, libgtk3.0 3.0.12-1 and libwxgtk 2.8.10-3.1.

[Loaden]

Works well in here.

Project's base path: /home/loaden/DengYC/Projects/baby/
Project's common toplevel path: /home/loaden/DengYC/Projects/baby/
Caching GCC dir: /usr/include/c++/4.5
Caching GCC dir: /usr/include/c++/4.5/x86_64-linux-gnu
Caching GCC dir: /usr/include/c++/4.5/backward
Caching GCC dir: /usr/local/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include-fixed
Caching GCC dir: /usr/include/x86_64-linux-gnu
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse with priority: '/usr/include/c++/4.5/cstddef'
Add 1 priority parsing file(s) for project 'baby'...
Added 1 file(s) for project 'baby' to batch-parser...
Create new parser for project 'baby'
Starting batch parsing for project 'baby'...
NativeParser received parser end event.
Project 'baby' parsing stage done!
Project 'baby' parsing stage done (94 total parsed files, 4181 tokens in 0 minute(s), 0.279 seconds).
Updating class browser...
Class browser updated.
CodeCompletion received parser end event.

[Jenna]

it also works fine with the build from my repo, but still fails if build C::B on my working system.
I just recompiled C::B with gcc 4.5 instead of 4.6, but the not-catch-the-parser-events-issue remains.

[Loaden]

it also works fine with the build from my repo, but still fails if build C::B on my working system.
I just recompiled C::B with gcc 4.5 instead of 4.6, but the not-catch-the-parser-events-issue remains.

Try to remove the default.conf

[Jenna]

it also works fine with the build from my repo, but still fails if build C::B on my working system.
I just recompiled C::B with gcc 4.5 instead of 4.6, but the not-catch-the-parser-events-issue remains.

Try to remove the default.conf

It does not change anything, but I don't know what the default.conf should have to do with event handling.

[Jenna]

The attached patch seems to fix the event-handler issue and should not break anything other.

Can you please test it ?

It does not fix the incorrect parsing of multiple projects in one workspace.