Author Topic: Clang CC  (Read 208527 times)

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #90 on: December 09, 2015, 01:36:04 pm »
yvesdm3000
My pleasure. I want the plugin to work correctly and efficiently almost as much as you do, I guess.

Offline Calmarius

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: Clang CC
« Reply #91 on: December 17, 2015, 03:24:35 pm »
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?

« Last Edit: December 17, 2015, 03:33:09 pm by Calmarius »

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #92 on: December 17, 2015, 03:35:10 pm »
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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Clang CC
« Reply #93 on: December 17, 2015, 09:14:12 pm »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Clang CC
« Reply #94 on: December 20, 2015, 10:46:24 pm »
@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.)

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #95 on: December 21, 2015, 12:06:19 am »
Alpha
You can attach to the running CB when it's already frozen and at least to lookup the call stacks.

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Clang CC
« Reply #96 on: December 21, 2015, 01:32:23 am »
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.)

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #97 on: December 21, 2015, 03:02:50 pm »
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
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Clang CC
« Reply #98 on: December 21, 2015, 04:52:48 pm »
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).

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #99 on: December 22, 2015, 06:06:59 am »
Is it threadsafe ?

Yves
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Clang CC
« Reply #100 on: December 22, 2015, 06:17:55 am »
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.
« Last Edit: December 22, 2015, 06:19:28 am by ollydbg »
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.

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #101 on: December 22, 2015, 06:40:35 am »
fprintf was a good choice then. I will probably copy the logger from the native CC, no need to reinvent the wheel.

Yves
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #102 on: December 22, 2015, 08:29:37 am »
The devel-branch now uses the CCLogger from the regular CodeComplete plugin.

Yves
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #103 on: January 23, 2016, 03:44:15 pm »
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
Clang based code completion for Code::Blocks:   http://github.com/yvesdm3000/ClangLib

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Clang CC
« Reply #104 on: January 24, 2016, 03:33:13 pm »
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 ).
« Last Edit: January 24, 2016, 03:37:55 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ