Clang CC

[oBFusCATed]

Btw. how is it going with integrating the plugin into codeblocks-contrib?

This one will land in the core someday. This is not a contrib plugin in.

For codeblocks-contrib, not sure if I am going to do this immediately, I think the plugin needs restructuring first. I want to split the plugin into pieces:

If you want to split this in multiple cb plugins, keep in mind that cb gets slower to start the more plugins there are installed (no matter if enabled or disabled).
Also do you really have added so much code you need to separate it into different pieces?

[yvesdm3000]

Btw. how is it going with integrating the plugin into codeblocks-contrib?

This one will land in the core someday. This is not a contrib plugin in.

For codeblocks-contrib, not sure if I am going to do this immediately, I think the plugin needs restructuring first. I want to split the plugin into pieces:

If you want to split this in multiple cb plugins, keep in mind that cb gets slower to start the more plugins there are installed (no matter if enabled or disabled).
Also do you really have added so much code you need to separate it into different pieces?

You do have a good point there. I would mostly do it so there would be room for other plugin developers to use Clang functionality without having to hack on the existing plugin. The best way to do that is to actually use this API ourselves and allow others replace certain behaviours.

Yves

[l_inc]

yvesdm3000

Obviously we can't assume users will always have enough memory to store that in memory, especially for pretty large projects.

Well, I have 16GBs in my work laptop, and I would appreciate an option to not drain my SSD of life with temporary stuff. Besides, you would still need to be able to handle low disk space situations, so why wouldn't you leverage the same out-of-space-avoidance mechanism in memory?

it's better to have ALL files parsed into AST trees. [...] So for example 'goto implementation', it would first look in any TU in memory, if it can't find it, it would go into a slower mode and open each PCH file one by one and see if it can find what it's looking for.

Yes, and for the option of no on-disk ASTs it would be necessary to parse all the remaining TUs (a progress bar would make sense), but that's the price for not having enough cache space, no matter if it's on disk or in memory.

[Alpha]

yvesdm3000

it's better to have ALL files parsed into AST trees. [...] So for example 'goto implementation', it would first look in any TU in memory, if it can't find it, it would go into a slower mode and open each PCH file one by one and see if it can find what it's looking for.

Yes, and for the option of no on-disk ASTs it would be necessary to parse all the remaining TUs (a progress bar would make sense), but that's the price for not having enough cache space, no matter if it's on disk or in memory.

The support I had initially attempted for in plan of this is TokenDatabase (roughly) keeps track (in memory) of where main definitions exist; then if any of those ASTs are not currently loaded, the could be found directly (not implemented), instead of having to re-parse the entire project.  The project does need to be parsed once at least, and this index probably should be serialized for searching to be useful between sessions.

[l_inc]

Alpha
This would only help with "find implementation". But "find all references" would still require to traverse the complete set of ASTs. So I support the TokenDatabase idea with respect to keeping it in memory for "find implementation" optimization, but no serialization, because re-/creation of all the non-existent ASTs is still needed for other things.

[yvesdm3000]

Yes TokenDatabase is used as a 'global' database, but does not contain everything.

When you'd look for references or anything else that would take some time, it should certainly show a dialog-box with a progress bar.

For the splitup, I've settled with an internal splitup to keep things organized and less spaghetti, so only 1 plugin but different components inside. The only drawback is that the toolbar is named 'ClangLib', which is an ugly name for it.

Yves

[yvesdm3000]

Hi,

I've put a binary up on the GitHub page. This version is compiled for Ubuntu 15.10

Don't expect a speed-wonder, but it does work and doesn't stop the user from typing.
You'll also have to wait a little after startup since it will still be parsing the files in the background and obviously you can't have Code-Completion yet when the file is not yet parsed. One of the next steps to take is to cache Translation Units to disk so that next time you open the project, it can use cached values.

I also implemented the toolbar that is now using Clang and is mostly a copy of the toolbar from the regular CodeCompletion plugin but is obviously driven by data coming out of Clang. There are still some limitations in the toolbar but nothing that prevents you from using it.

Yves

[yvesdm3000]

I just pushed some more commits to the master branch with some more fixes  in it and also fixes for the inline diagnostics, and asynchronous documentation (this was still an operation that kept the UI hanging).

I'll put a new binary up soon, and look into building a binary for windows using MingW.

Yves

[yvesdm3000]

Hi,

I added a .cbplugin file for ubuntu 15.10 to the 0.3 release page for your convenience.

https://github.com/yvesdm3000/ClangLib/releases/tag/0.3

Yves

[yvesdm3000]

yvesdm3000

Obviously we can't assume users will always have enough memory to store that in memory, especially for pretty large projects.

Well, I have 16GBs in my work laptop, and I would appreciate an option to not drain my SSD of life with temporary stuff. Besides, you would still need to be able to handle low disk space situations, so why wouldn't you leverage the same out-of-space-avoidance mechanism in memory?

it's better to have ALL files parsed into AST trees. [...] So for example 'goto implementation', it would first look in any TU in memory, if it can't find it, it would go into a slower mode and open each PCH file one by one and see if it can find what it's looking for.

Yes, and for the option of no on-disk ASTs it would be necessary to parse all the remaining TUs (a progress bar would make sense), but that's the price for not having enough cache space, no matter if it's on disk or in memory.

Hi l_inc,

I'm looking now at generating PCH files to accelerate the startup. I think I can manage to make this functionality optional since in any case I can never assume a PCH file is always available for any source file...

Yves

[l_inc]

yvesdm3000
Thank you for taking that into account. Thing is that I'd probably leave the functionality enabled in most cases, but the storage location would be on a RAM drive. This would allow to have accelerated startup until reboot.

[yvesdm3000]

Another push: initial configuration dialog and added some quick-exit situations for code-completion.

I'm currently wondering how I could implement the Clang 'fixit' functionality. These are warnings/errors where Clang can suggest what exactly needs to be done, like adding extra brackets or adding ';' at the end, with precise locations etc. I don't want to execute these fixits automatically since the user might have another intention, so I want something where I do insert them temporarily, but are highlighted with some backgroundcolor and if the user goes to another line, these are removed again, but then I need something visual to actually apply the fixit...

If someone has ideas, I'm open to suggestions!

Yves

[oBFusCATed]

Show a popup with a button, but please add this in the C::B's SDK and post  a patch for it, thus other CC implementers can benefit from it.

[l_inc]

yvesdm3000

I want something where I do insert them temporarily, but are highlighted with some backgroundcolor and if the user goes to another line, these are removed again

This way the original code will potentially be overwritten, and the fix suggestion might mislead if not appropriate. If you don't make the fix suggestions persistently visible, then I'd prefer a popup as oBFusCATed suggested.

However the persistently visible warnings and errors is what I like a lot about ClangCC. Thus embedding a fix suggestion in-between the lines together with the actual warning/error should be even better. But I guess this way is not as compatible with multiple fix suggestions, as a popup.

but then I need something visual to actually apply the fixit

As for me a couple of shortcuts would suffice (fix, show another fix, goto next warning/error, goto previous warning/error), but I like when GUI provides multiple ways of doing something, so I would prefer to see these buttons on the ClangCC toolbar as well. Buttons inside of a popup seem to me an overkill.

[oBFusCATed]

Check how it is done in XCode, I've heard that theirs is a good solution to this problem.
Also adding shortcuts is fine, but they should be the second option, because most of the times they are not obvious and hard to find by new users of the feature.

One option is to use the scintilla's inline annotations, but I don't know if you can add buttons in it.
Another is to use some kind of an editor marker that when clicked pops up some ui.