Author Topic: Clang CC  (Read 145936 times)

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #105 on: January 24, 2016, 08:06:54 pm »
Hi MortenMacFly,

I committed your proposed fix on master. Looks like this was only overlooked in clangdiagnostics.cpp, the other places has the "RemoveAllEventSinksFor(this);".

Many thanks for pointing this out!

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

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9621
Re: Clang CC
« Reply #106 on: February 06, 2016, 08:44:33 pm »
I committed your proposed fix on master. Looks like this was only overlooked in clangdiagnostics.cpp, the other places has the "RemoveAllEventSinksFor(this);".
OK, thank you. BTW: There are many more crash candidates. Unfortunately if you use this plugin on Windows it will definitely crash sooner or later. I've never been able to run a complete C::B session w/o crash. :-/

Another thing: Please don't use code that is not portable. alloca for example is very bad and should never be used. Also, currently your git HEAD is broken because it seems you did commit a file (tokendatabase.cpp) w/o resolving conflicts first.

If possible, I would recommend that you test this plugin from time to time on Windows. Be careful with hacks, they usually don't work on other platforms. If it compiles on Windows, I can help with that from time to time... just guide me what to do.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9621
Re: Clang CC
« Reply #107 on: February 06, 2016, 09:00:50 pm »
Here comes another reproducible crash:
* have Clang plugin enabled
* disable the plugin in plugin manager
* search in files so that the result (listlog) has some entries
* try to open a file from the log (double-click)
-> Crash
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #108 on: February 07, 2016, 03:31:01 pm »
OK thank you for the bug report, I'll look into it as soon as I have some time for it.

I mostly test the plugin using my day-to-day work which is Linux-based ...

Maybe I should have some sessions on windows just so that I can try things, or have some unit-tests to run, it would certainly improve reliablity...

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

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #109 on: February 08, 2016, 09:50:29 am »
I was able to reproduce the problem and I fixed it in master. Thanks for the bugreport !

There is however something fishy in Manager::Get()->RemoveAllEventSinksFor() that I'll investigate later.

Yves

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

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #110 on: February 09, 2016, 11:51:36 am »
Another thing: Please don't use code that is not portable. alloca for example is very bad and should never be used.
A question, where did you see the use of alloca ?

Please always use the "master" branch. The "develop" branch is mostly playground for new features and is hopelessly unstable right now due to some problems inside the clang-library itself.

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

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Clang CC
« Reply #111 on: February 09, 2016, 03:30:02 pm »
By the way, I would like to help clean up code when I have time.  Do you think you will have a set of commits ready for me to pull upstream anytime soon?

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #112 on: February 09, 2016, 04:24:45 pm »
Hi Alpha,

I'm not ready to push this upstream yet:

I'm mostly working on the tokendatabase right now, using an indexing job to parse all files within the workspace. It's a complex matter, with tokens parsed from unsaved files going into the database but you don't want half of the tokens available to the point where it's parsing in any db lookup from the editor, and we only want it persisted when the file is saved (otherwise you type some symbols, they get parsed, inserted in the database and then you close without saving ==> tokens still in the database) etc...

I first tried with a revision number, but that became hopelessly complex so I dropped this in favour of different instances of tokendatabases that can be merged when needed or dropped on failure or cancellation. It has a superior advantage that a thread can update it's own tokendatabase and it gets merged into the main database after the file is successfully parsed.

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

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9621
Re: Clang CC
« Reply #113 on: February 09, 2016, 08:07:20 pm »
By the way, I would like to help clean up code when I have time.
You could also just fork from Yves repo and send pull requests to Yves...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Clang CC
« Reply #114 on: February 10, 2016, 01:49:11 am »
By the way, I would like to help clean up code when I have time.
You could also just fork from Yves repo and send pull requests to Yves...
I have done that already.  However, since it would likely include a decent number of whitespace edits, I was trying to avoid merging troubles.

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #115 on: February 10, 2016, 11:50:51 am »
OK, thank you. BTW: There are many more crash candidates. Unfortunately if you use this plugin on Windows it will definitely crash sooner or later. I've never been able to run a complete C::B session w/o crash. :-/

Another thing: Please don't use code that is not portable. alloca for example is very bad and should never be used. Also, currently your git HEAD is broken because it seems you did commit a file (tokendatabase.cpp) w/o resolving conflicts first.

If possible, I would recommend that you test this plugin from time to time on Windows. Be careful with hacks, they usually don't work on other platforms. If it compiles on Windows, I can help with that from time to time... just guide me what to do.

OK, it certainly looks like you are viewing the 'devel' branch since the alloca and merge-conflict stuff are in there. It should actually be named 'experimental' and contains a lot of hacks and other things that certainly should not be in master (like you pointed out).
To cope with this misunderstanding I'll create a new branch which is named 'experimental' and I hope it should be more clear for people trying stuff.

I now used the build from the 'master' brand on 16.01 on windows for a couple of hours without any crashing-issue. There is however some desync issue where *rarely* the chosen code-completion is not the one inserted in the editor that I'll look into shortly.

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

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9621
Re: Clang CC
« Reply #116 on: February 10, 2016, 08:00:30 pm »
OK, it certainly looks like you are viewing the 'devel' branch since the alloca and merge-conflict stuff are in there. It should actually be named 'experimental' and contains a lot of hacks and other things that certainly should not be in master (like you pointed out).
Ah - ok, that might be my mistake. I though "devel" is where development occurs and master you only use to sync with Alpha. Good to know. So I'll switch to master and try again...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #117 on: February 20, 2016, 09:12:33 am »
I made another push to master: Mostly speed and stability improvements.

https://github.com/yvesdm3000/ClangLib

Regarding code-completion, I think that is feature complete. I'm moving on to code-refactoring things.

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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5453
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Clang CC
« Reply #118 on: February 21, 2016, 03:23:38 pm »
I have some questions:
1, what are the m_UnsavedFiles means in all the Jobs? (in clangproxy.h file), does every job need such parameter?
2, about SyncJob, you just want to run the task in worker thread, but the mainthread is just blocked, is it possible our ccmanager supply some interface which support synchronized request? I mean if ccmanager ask a code completion list, it just returned, and let a specific cc plugin to do the job to fill something(through synchronized api), and this way, we won't let the main gui thread get blocked

EDIT: I would suggest you can add some doxygen style document to the source code, so that people(include me) can read and understand or debug the code easily.
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 #119 on: February 21, 2016, 05:00:48 pm »
Hi Ollydbg,

I have some questions:
1, what are the m_UnsavedFiles means in all the Jobs? (in clangproxy.h file), does every job need such parameter?
This is to give Clang access to the files that are open in the editor and are not saved, e.g. the changes that are in the buffer of the editor.
These are duplicated since Clang runs in a thread and the user might start changing them. It results in some nice asserts in libclang when not deep-copied. One might optimize this by only passing the ones that are needed, but it's more complicated than at first sight:
The user might have added an #include statement to an Unsaved header file and we haven't parsed the #include statement and thus we are unaware there is an UnsavedFile we need to pass, so for now I just chose to pass them all and postpone optimizations for later. It has a low impact and a lot less that I would have guessed at the start, so this would have been a premature optimization.

Quote
2, about SyncJob, you just want to run the task in worker thread, but the mainthread is just blocked, is it possible our ccmanager supply some interface which support synchronized request? I mean if ccmanager ask a code completion list, it just returned, and let a specific cc plugin to do the job to fill something(through synchronized api), and this way, we won't let the main gui thread get blocked
SyncJob is mostly 'optionally' synchronous, e.g. the caller can wait for it with a timeout. Initially I didn't understand how the C::B 'GetAutocomplist' worked, it seemed like a synchronous operation to me so I figured I'd start a code-completion and when it took too long, just return empty and be ready for the next request. Later on I saw you can actually do the same code-completion request once the threaded one is finished so I figured I keep the timeout-implementation since it keeps the total operation simple&fast when the clang-operation is faster than 20 milliseconds. So theoretically the 'SyncJob' could be removed from the project again, or at least for the CodeCompleteAtJob.
On the other hand, I do think the 'GetAutocomplist'-call in the cc-plugin framework looks like an afterthought, something with a request event and a response event would probably have been much nicer, but I'm unaware of the lowlevel choices and scintilla if that would even be possible.

Quote
EDIT: I would suggest you can add some doxygen style document to the source code, so that people(include me) can read and understand or debug the code easily.
Sure thing. I'll add it to the top of my todo list for you.

Yves

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