Clang CC

[l_inc]

yvesdm3000
My pleasure. I want the plugin to work correctly and efficiently almost as much as you do, I guess.

[Calmarius]

Will this clang CC solve the build configuration problem?
Most open source projects out there are compiled by the "./configure; make" combo.
And makefiles and configurations can set bazilions preprocessor directives and extra include paths. Can it go through these and still parse correctly?

[l_inc]

Calmarius
The configuration you use for editing the source code is not necessarily the one derived by a particular invocation of configure on your system. So it's not the perfect choice to directly rely on it.

As for Clang CC, it relies on the configuration specified in the CB project. If you want the code completion and diagnostics to reflect the full configuration used for building the project, you need to setup the project build options accordingly.

[MortenMacFly]

Will this clang CC solve the build configuration problem?
Most open source projects out there are compiled by the "./configure; make" combo.
And makefiles and configurations can set bazilions preprocessor directives and extra include paths. Can it go through these and still parse correctly?

How should it work? Configure is there to setup the code for your platform and to your needs / options / compilers... So unless you provide magic balls how on earth should any parser know and resolve this?

The only right thing to do it to actually run configure and have the right setup in place.

[Alpha]

@yvesdm3000 I have pulled your recent work, and am running into an odd issue.  If I type ; or if I press enter, C::B freezes after about 0.5 seconds.  However, if C::B is running under gdb, there are no freezes.  Is there some additional needed configuration step?  (The only local changes I added are for correct paths in the .cbp.)

[l_inc]

Alpha
You can attach to the running CB when it's already frozen and at least to lookup the call stacks.

[Alpha]

Thanks.  Turns out it was the debug printing attempting send to the console when C::B was started full GUI mode that caused the freeze.  (Starting C::B inside a terminal works just fine.)

[yvesdm3000]

Pretty interesting, I always run it from the terminal to get the debugging output... Glad to see you're up and running again. Maybe we should move the debug-output to a macro or something.

I'm currently tackling the TokenDatabase to span the whole project/workspace with persistence ondisk. This is needed for useful 'go to implementation' and most refactoring operations. For normal Code-completion this is not really necessary, but some results-filtering is currently still disabled because I don't want to make it another thread-context-switch, I think it should be done in the same flow where code-completion was requested. It's not hard, but I don't really miss it myself.

Yves

[Jenna]

Why not use the logmanager ?

Code: cpp

Manager::Get()->GetLogManager()->DebugLog(F(_("")));

or

Code: cpp

Manager::Get()->GetLogManager()->DebugLogError(F(_("")));

This logs to debug-log if available and/or to console (if open).

[yvesdm3000]

Is it threadsafe ?

Yves

[ollydbg]

Is it threadsafe ?

Yves

NO, please see the whole thread discussion here: F() function is not thread safe?, also the logger function is not thread safe.

EDIT: That's why the native cc plugin use it's own logger.

[yvesdm3000]

fprintf was a good choice then. I will probably copy the logger from the native CC, no need to reinvent the wheel.

Yves

[yvesdm3000]

The devel-branch now uses the CCLogger from the regular CodeComplete plugin.

Yves

[yvesdm3000]

Did another push to the 'devel'-branch that makes the tokendatabase persistent and reindexes at project load. I'm  now stuck on a situation where Clang sometimes crashes when reading a PCH file so I'll probably skip using PCH files and reparse the file when needed and implement the PCH-optimization later.

My current goal is to make "Goto implementation" work correctly when the file is not yet open.

Yves

[MortenMacFly]

I also noticed some fatal crash bug: If you disable the plugin and then open an editor, C::B will crash immediately. The reason is that you don't check whether or not the plugin is still enabled. Therefore, the pointer to m_pClangPlugin will be invalid when accessed in clangdiagnostics.cpp here:
(line 145:)         m_TranslUnitId = m_pClangPlugin->GetTranslationUnitId(fn);
Probably that is true on other places, as well... be careful when developing...

The proper implementation is also to detach from the event queue and event sinks, if the plugin is disabled, so pleae add:

Code

    // remove registered event sinks
    Manager::Get()->RemoveAllEventSinksFor(this);

...in ClangDiagnostics::OnRelease( IClangPlugin* pClangPlugin ).