Clang CC

[yvesdm3000]

Thansk for the fix yves, I managed to compile and load it.

I haven't looked at the code yet, do I need to do anything else apart from installing the plugin to enable it (like disabling old CC) ? Any advice on how to stresstest it ?

I always disable the old CC. I don't know at all how well they play together.

Just know that 'goto implementation' currently only works on loaded Translation Units and you can have a maximum of 5 loaded at the same time. It's a tokendatabase thing and been working to solve that for a while... It's not easy and if I would load the whole database in its current implementation for all files for my customers project, it takes a couple of gigabytes of memory, which is not acceptable.
Know that I use this plugin daily for some good coding on a pretty big project.

Also the CodeCompletion seems to be invoked a bit too often which makes it 'a little noticeable' slow on a virtual machine (not on a real PC) and sometimes CC-event gets triggered when they shouldn't, but it's not something that bothers me right now.

Class browser is not implemented at all and it looks I should try to learn from the mistakes the regular CC-plugin made. I haven't started this work at all yet.

Yves

[teto]

Ok I have it working. A codeblocks reboot might be necessary or maybe it's because I disabled the regular CC-plugin but I now see the "tooltips" unlike yesterday.
My project is a custom project, hence the .cbp file does not contain the compilation flags etc... is there a way to pass on a compile_commands.json ?

I was curious to test this plugin compared to YouCompleteMe + Vim which is often not capable of finding the definition. The number of translation unit seems indeed to be the crux of the matter.
I was curious how to fix it and I stumbled on this topic that could be of interest to you:
https://github.com/Valloric/ycmd/pull/180

To sum up, clang devs think of providing a standard tool for cross TU interrogation, so maybe you should not spend too much time on this (or do it upstream :p).

[yvesdm3000]

My project is a custom project, hence the .cbp file does not contain the compilation flags etc... is there a way to pass on a compile_commands.json ?

A trick that I use is to setup the .cbp file to not use an external makefile, do a theoretical configuration with mostly the C++ language and the header search paths and then switch back to using an external makefile.

The Clang-CC plugin doesn't check if the makefile is extenal and can still query the part of the settings that are theoretically disabled.

I was curious to test this plugin compared to YouCompleteMe + Vim which is often not capable of finding the definition. The number of translation unit seems indeed to be the crux of the matter.
I was curious how to fix it and I stumbled on this topic that could be of interest to you:
https://github.com/Valloric/ycmd/pull/180

To sum up, clang devs think of providing a standard tool for cross TU interrogation, so maybe you should not spend too much time on this (or do it upstream :p).

I used to use YouCompleteMe for a while but it had the same issue that I had with the initial implementation of this plugin: It blocks the UI too often preventing me to type. I will be doing essentially the same thing like they suggest: Parse every file in the project and build a token-to-file relationship. This way the plugin knows which file to parse to go find the implementation.
There is actually not a lot that Clang can do about it, in the end it needs to parse every file anyway to know what implementations it has. The intention is however to keep this indexing information to the bare minimum: Token->file and some flags that indicates if the token has a declaration, a definition or reference. This comes to a single list of token strings and 3 ints for each token-file relationship and this information will be serialized so that you can have a kick-start when initially starting up the project. (an optional 4'th int might be added later with a checksum for better fine-grained lookups.

Yves

[teto]

The blocking UI problem is in general solved by neovim (a great vim fork), though I dunno for YCM in peculiar, my computer is just too fast to notice

I've given https://github.com/Andersbakken/rtags a try this afternoon. Out of the 3 vim plugins mentioned on the webpage, I could only make https://github.com/lyuts/vim-rtags work. I've not had the time to see how it compares with YCM but  from the description it looks promising.

[yvesdm3000]

I pushed a small fix on master for when code-completion seems to be invoked when you don't want to.

Yves

[yvesdm3000]

I just pushed the changes for the tokendatabase to make 'goto implementation' work much better to the 'staging' branch so whoever wants to test is free to do so.

The tokendatabase is however not yet persistent so each time you load a project, the plugin will do a complete reindexation.
What prohibits me to implement this persistence is that the tokendatabase should be linked to a project and not the workspace because you could (theoretically) have 2 separate projects each have a class that share the name but not the implementation. In further stages when can start renaming symbols this might even become more important.

Yves

[MortenMacFly]

What prohibits me to implement this persistence is that the tokendatabase should be linked to a project and not the workspace because you could (theoretically) have 2 separate projects each have a class that share the name but not the implementation.

Please keep in mind that it could also be that two targets in a project share the same class with different implementations. there are quite some projects around where that is the case...

[yvesdm3000]

Are you referring to having a #define set on a target that selects some class/interface/code?
If that's the case, that is just covered by clang itself and me passing its compile options. I also reparse the translation units when configuration options are changed. I should however check if this is also done when the target is changed, so good point.

If it's something else that I'm not aware of, please specify.

Yves

[yvesdm3000]

I just landed the persistent tokenindex database, split out per loaded project.

It's pushed on the "staging" branch right now. I'll leave it stabilize for now until I merge it onto the master branch.

Next step will be the class-browser, but I need to figure out how I can get this information out of Clangs AST.

Yves

[MortenMacFly]

If it's something else that I'm not aware of, please specify.

I meant that if you say you'll need a token database per projects I say its better per target. Because the very same reason why you don't do it per workspace also applies to projects due to targets.

If you can manage that differently somehow I am happy.

[yvesdm3000]

If it's something else that I'm not aware of, please specify.

I meant that if you say you'll need a token database per projects I say its better per target. Because the very same reason why you don't do it per workspace also applies to projects due to targets.

If you can manage that differently somehow I am happy.

I think I understand why. You could have a different set of files associated on a target, but that does not necessarily mean it's a problem since the indexdb will contain symbols of all files unless you want to use ClangCC to hint for upcoming linking problems e.g. you're code-completing on a class that is not defined for your target.

It becomes a real problem:

• When you have separate files defining the same symbol (for example: a mock and the real implementation of a class). Even still ClangCC will cope with this and give you the unified set of symbols and the implementation-lookup would return multiple choices. I must admit it's not ideal and I don't like it.
• 1 file that contains a different set of symbols selected by a #define set in the settings of the target. Now that is a big issue: In theory clang should parse this file for each target otherwise we simply don't have the symbols needed to do all what ClangCC is supposed to do.

And to make things worse, if I would have to multiply the token-databases with the different targets possible, it would make the memory-footprint huge.

However there is 1 distinct difference with the project-splitup: There can only be 1 target selected at the same time so to cope with the memory-footprint, we could unload and load a different tokendatabase when the target is switched (and flush the in-memory Translation Units since they might need new compile command arguments).

Yves

[l_inc]

yvesdm3000
Hi. I like the plugin a lot, but there are some problems I encountered so far that annoy me (present in this week's staging branch as well):

1) Code completion doesn't work for labels: no matter forward or backward referenced

2) Code completion doesn't work for fields of unions/structures inside compound literals (in C):

Code

typedef union mystruct_t_
{
  uint32_t raw;
  struct
  {
    uint32_t offset:12;
    uint32_t reserved:24;
  } fields;
} mystruct_t;

uint32_t const value =
      ((mystruct_t) { .fields.reserved = 1 }).raw;
//CC not working here ^

3) Header files are often parsed incorrectly as main files in their own translation unit. Every file in a project has a property (Properties... -> Build -> Compile file) specifying whether it is a separate translation unit. This property could be a basis for the decision. Besides it would be nice to be able to quickly switch every such header between existing translation units, in which the header file is included, through a quickly accessible menu, because it's not uncommon to have (very) different parsing of the same header depending on the translation unit.

As a side note, unfortunately clang doesn't compile things like static size_t const tmp = "Hello"-"Hello";, which results in a spurious error-diagnostic. But I guess that should rather be reported to the clang developers: even though the standard doesn't guarantee it compiles, it better would as in gcc.

[yvesdm3000]

yvesdm3000
Hi. I like the plugin a lot, but there are some problems I encountered so far that annoy me (present in this week's staging branch as well):

Hi l_inc,

I highly appreciate the feedback! Beware the staging is still a bit 'wet' in the way that the index-database still has issues.

1) Code completion doesn't work for labels: no matter forward or backward referenced

Beside the generic nagging about gotos etc (but I'm also realistic: I should not care about what someone does or even have to do at times!), I fear that the current code-completion support comes completely from the libclang library. I give it the translation unit and a position and the library returns me a list of code-completions where we only filter out constructors and operators when they are not appropriate. Nevertheless I think we should be able to retrieve the labels within the function scope and detect the goto statement and do code-completion ourselves.

2) Code completion doesn't work for fields of unions/structures inside compound literals (in C):

Code

typedef union mystruct_t_
{
  uint32_t raw;
  struct
  {
    uint32_t offset:12;
    uint32_t reserved:24;
  } fields;
} mystruct_t;

uint32_t const value =
      ((mystruct_t) { .fields.reserved = 1 }).raw;
//CC not working here ^

It might be libclangs fault, or maybe we are not giving it the correct position. We always go back to the start of the word, that is what libclang wants, but I'm unsure if we do it correctly in this case. I'll try to look at this case later next week.

3) Header files are often parsed incorrectly as main files in their own translation unit. Every file in a project has a property (Properties... -> Build -> Compile file) specifying whether it is a separate translation unit. This property could be a basis for the decision. Besides it would be nice to be able to quickly switch every such header between existing translation units, in which the header file is included, through a quickly accessible menu, because it's not uncommon to have (very) different parsing of the same header depending on the translation unit.

Yep, I'm completely aware of this problem. There is some code that should cope with this but it's buggy and disabled. The way I see it is that the currently focussed translation unit will be checked first if it handles the newly focussed header file. This way you could force the 'view' of the header file by going to the header/source file that does some defines before the #include statement and when you would then go to the header file, you'd see it trough that translation unit.

As a side note, unfortunately clang doesn't compile things like static size_t const tmp = "Hello"-"Hello";, which results in a spurious error-diagnostic. But I guess that should rather be reported to the clang developers: even though the standard doesn't guarantee it compiles, it better would as in gcc.

That's a drawback of using libclang for code-completion and gcc as a compiler. It would be very hard to fix this since you're mixing up 2 compilers... Best would be to use clang as a compiler too, but often you don't have that option. (Same for me for my other projects. GCC is the only compiler where the product compiles, nevertheless I find clangcc very usefull for code-completion.

Yves

[l_inc]

yvesdm3000

Beside the generic nagging about gotos etc (but I'm also realistic: I should not care about what someone does or even have to do at times!)

I'm very fastidious with respect to coding style, and I always try to find the cleanest and clearest way of doing things. Starting to use goto's was (once) a result of a critical analysis of my C code. While I totally support most of the critics of goto, there's one single case where it does a better job in supporting clean and clear code in C than anything else. And that's error handling. Especially when you handle resource allocation errors while allocating three or more resources in a function. That's a generally accepted application of goto's and the only one I make use of in my code. In C++ RAII is in many cases a better alternative, but we don't have that in C.

Aside from the justification of goto's used in a very limited way, there's indeed another argument, which you've already mentioned. That is, code completion should support possible language constructs rather than some specific coding styles. Supporting the latter could only be an optional additional bonus.

Nevertheless I think we should be able to retrieve the labels within the function scope and detect the goto statement and do code-completion ourselves.

Well, thank you for considering that option. However I expected libclang to be somewhat more clever in that respect. If it doesn't support code completion for labels, then I'd first bugreport that to the libclang developers.

I'll try to look at this case later next week.

OK. Thanks for taking your time looking into that.

This way you could force the 'view' of the header file by going to the header/source file that does some defines before the #include statement and when you would then go to the header file, you'd see it trough that translation unit.

I see this kind of implementation as a possible temporary workaround. But a drop-down or a quick popup with an assignable hotkey (like the one you have on Ctrl+Tab) seems to me more user-friendly.

GCC is the only compiler where the product compiles, nevertheless I find clangcc very usefull for code-completion

Totally. And in general you're right regarding the issues of using different compilers. However clang developers target broad compatibility with gcc, and I'm gonna find some time to report at least this little issue to the clang developers, as supporting string merging in this specific case is arguably better than not supporting, even though this goes beyond the requirements imposed by the C standard.

[yvesdm3000]

yvesdm3000
I'm very fastidious with respect to coding style, and I always try to find the cleanest and clearest way of doing things. Starting to use goto's was (once) a result of a critical analysis of my C code. While I totally support most of the critics of goto, there's one single case where it does a better job in supporting clean and clear code in C than anything else. And that's error handling. Especially when you handle resource allocation errors while allocating three or more resources in a function. That's a generally accepted application of goto's and the only one I make use of in my code. In C++ RAII is in many cases a better alternative, but we don't have that in C.

It looks like I've been doing too much C++ the last 2 years. I actually agree about using goto's and resources in C. It's not an ideal solution but there is no other clean alternative. Some do the for( ; ; ) and break thing but I find it cluttering and misuse of the for loop. I've also seen some code that have defines to hide that for-loop trick, but had side-effects on its own, especially around the warnings/errors it emits when doing something wrong.

Well, thank you for considering that option. However I expected libclang to be somewhat more clever in that respect. If it doesn't support code completion for labels, then I'd first bugreport that to the libclang developers.

I'll try to file a bugreport for this.

I see this kind of implementation as a possible temporary workaround. But a drop-down or a quick popup with an assignable hotkey (like the one you have on Ctrl+Tab) seems to me more user-friendly.

I'm not sure about the details on what you propose in the sub-menu. I guess it should have a list of filenames (e.g. the top-parent of the translation unit) to select under which context you wish to view the header file?

Yves