Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang CC
yvesdm3000:
--- Quote from: MortenMacFly on May 27, 2016, 09:10:40 pm ---
--- Quote from: yvesdm3000 on May 14, 2016, 07:40:14 am ---If it's something else that I'm not aware of, please specify.
--- End quote ---
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.
--- End quote ---
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 ^
--- End code ---
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:
--- Quote from: l_inc on June 04, 2016, 01:50:30 am ---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):
--- End quote ---
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.
--- Quote ---1) Code completion doesn't work for labels: no matter forward or backward referenced
--- End quote ---
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.
--- Quote ---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 ^
--- End code ---
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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
--- Quote ---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!)
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---I'll try to look at this case later next week.
--- End quote ---
OK. Thanks for taking your time looking into that.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---GCC is the only compiler where the product compiles, nevertheless I find clangcc very usefull for code-completion
--- End quote ---
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:
--- Quote from: l_inc on June 05, 2016, 12:49:06 am ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
I'll try to file a bugreport for this.
--- Quote ---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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version