Author Topic: Clang CC  (Read 250780 times)

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #165 on: June 05, 2016, 03:34:00 pm »
yvesdm3000
Quote
Some do the for( ; ; ) and break thing but I find it cluttering and misuse of the for loop
Yes, that's using a more complicated mechanism to simulate a better fitting primitive one. This consideration also allows to view a do { /*...*/ } while(0); construct as a more appropriate replacement, although still ugly. I actually preferred nesting of the if (/*...*/) {/*...*/} construct. But in all cases that only stops further proceeding and therefore is only half of the story. The second half is to deallocate the resources, which needs more clutter of constructs. I used a switch with all fall-through cases:
Code
NTSTATUS HighlyNestedFun()
{
NTSTATUS ntStatus = STATUS_SUCCESS;
enum failure_stage {success, res1_failure, res2_failure, res3_failure, res4_failure, res5_failure}
failureStage = success;
HANDLE hRes1, hRes2, hRes3, hRes4, hRes5;

hRes1 = AcquireResource1();
if (!hRes1)
ntStatus = STATUS_INSUFFICIENT_RESOURCES1, failureStage = res1_failure;
else
{
hRes2 = AcquireResource2();
if (!hRes2)
ntStatus = STATUS_INSUFFICIENT_RESOURCES2, failureStage = res2_failure;
else
{
hRes3 = AcquireResource3();
if (!hRes3)
ntStatus = STATUS_INSUFFICIENT_RESOURCES3, failureStage = res3_failure;
else
{
hRes4 = AcquireResource4();
if (!hRes4)
ntStatus = STATUS_INSUFFICIENT_RESOURCES4, failureStage = res4_failure;
else
{
hRes5 = AcquireResource5();
if (!hRes5)
ntStatus = STATUS_INSUFFICIENT_RESOURCES5, failureStage = res5_failure;
else
{
//using acquired resources
}
}
}
}
}

switch (failureStage)
{
case success:
FreeResource5(hRes5);
case res5_failure:
FreeResource4(hRes4);
case res4_failure:
FreeResource3(hRes3);
case res3_failure:
FreeResource2(hRes2);
case res2_failure:
FreeResource1(hRes1);
case res1_failure:
}

return ntStatus;
}
But eventually I came to the conclusion that all this clutter is nothing but an odd simulation of a much clearer use of goto's. Limiting goto use to these cases only also contributes to code clearness, because the semantics of resource allocation error handling is then quickly recognized from the sole appearance of goto in the code.

Quote
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?
Yes. In contrast to your idea to switch back and forth between the file and possible roots of the corresponding translation units this also allows to cover some convoluted cases, in which the same file within the same project serves both as a root of a translation unit as well as an included file.
« Last Edit: June 05, 2016, 03:42:53 pm by l_inc »

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #166 on: June 05, 2016, 09:21:51 pm »
You can always post bugs and feature requests here:

https://github.com/yvesdm3000/ClangLib/issues

I've allready done it for the compound literals issue. I'll also add the header-tu-scope feature request too if you don't. ;-)

Yves

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

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #167 on: June 05, 2016, 10:42:42 pm »
yvesdm3000
Quote
You can always post bugs and feature requests here
Thank you. I have to think about creating an account on github first. :-)

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #168 on: June 16, 2016, 10:26:56 pm »
For those that like bleeding edge, I pushed a new feature on the 'staging' branch that allows you to apply the fixits automatically, but only if your cursor is at least 2 lines away from the fixit line. It is disabled by default so you'll have to enable it in the settings.

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

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #169 on: August 21, 2016, 03:21:07 pm »
Hi,

I pushed a new feature to the 'staging' branch that lets the user configure if they want the 'if/else/for/while' constructs in code-completion or not. While I was at it, I also added the feature where you can toggle if you want macros in code-completion or not.

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

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #170 on: August 21, 2016, 04:17:28 pm »
yvesdm3000
Hi. Did you have a look at the issue with header files parsed out of translation unit context? This issue results in literally every header file in my current main project being full of red diagnostics and no code completion works in the header files. I saw you had created an issue for that, just asking if you'll work on this in anytime soon.

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #171 on: August 21, 2016, 07:56:27 pm »
Hi l_inc,

Yes I briefly looked at that and tried enabling it again. The problem is that reparsing doesn't work correctly in that setup. This is because Clang caches all header files in a PCH (the preamble files in /tmp) and this obviously includes the header file we're modifying. Disabling this cache has a big impact on performance and I currently don't know (yet) how I should fix this. A quick fix might be that we disable this caching behaviour when we're working in a header file, but then again the performance degradation will still be there.

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

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #172 on: August 21, 2016, 08:19:19 pm »
yvesdm3000
Quote
Yes I briefly looked at that and tried enabling it again
What exactly do you enable?
Quote
The problem is that reparsing doesn't work correctly in that setup.
If I understand the problem correctly, it should be possible to make clang create the PCH cache for an include subtree of an include tree of a particular selectable translation unit. Meaning that you view the header file as a root of a virtual include tree that is terminated at the point of first inclusion of the header file in the original tree of the chosen translation unit. Essentially this way of parsing is a generalization of your current parsing for the case when the virtual include tree does not match the actual include tree that is built starting directly from the header file as the root.

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #173 on: August 21, 2016, 08:36:44 pm »
yvesdm3000
Quote
Yes I briefly looked at that and tried enabling it again
What exactly do you enable?
There is some lookup code where given a specific FileId it searches for an existing translation unit. This is currently disabled
Quote
Quote
The problem is that reparsing doesn't work correctly in that setup.
If I understand the problem correctly, it should be possible to make clang create the PCH cache for an include subtree of an include tree of a particular selectable translation unit. Meaning that you view the header file as a root of a virtual include tree that is terminated at the point of first inclusion of the header file in the original tree of the chosen translation unit. Essentially this way of parsing is a generalization of your current parsing for the case when the virtual include tree does not match the actual include tree that is built starting directly from the header file as the root.
<-- Really needed to read this a couple of times... The PCH cache creation is completely handled by Clang and is simply enabled by an option flag. Maybe we should find a way to handle this PCH cache ourselves?

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

Offline l_inc

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Clang CC
« Reply #174 on: August 21, 2016, 09:54:27 pm »
yvesdm3000
Quote
<-- Really needed to read this a couple of times... The PCH cache creation is completely handled by Clang and is simply enabled by an option flag.
I'm sorry for unclear expressions. I must have given an example of what interface I expect libclang to provide to achieve this. Ideally I expect libclang to allow to setup a callback. This callback should be called every time libclang processes the include directive. And the callback should allow to stop PCH generation. The resulting PCH then represents the result of processing of the subtree I was talking about. In case such a callback interface is not provided, it shouldn't be too complicated to add such an interface.

To say it in different words. You let libclang generate a PCH for translation unit of user's choice. You hook processing of the include directive. During PCH generation your hook/callback checks the file included by the directive. If this is the header file you are interested in, the hook should make libclang finalize PCH creation. This way created PCH is then used for code completion in the header file.

I know it sounds like a foolish speculation, but I can try to have a look at libclang's code and to add such a callback if clang really doesn't provide it or any equivalent interface.

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #175 on: August 22, 2016, 01:53:00 pm »
Sadly it's not that simple...

http://clang.llvm.org/doxygen/group__CINDEX__TRANSLATION__UNIT.html

However I need to experiment a little more and possibly look a bit at the clang code to see if I do pass the header-file as an "unsaved_file" it detects that and reparses the header file(s), maybe it would only work if the header-file is a first-level header file (e.g. specified directly in the .cpp file). Maybe it needs to be in the unsaved_file list at the initial parse to work or something like that...

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

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #176 on: September 28, 2016, 11:06:24 am »
Hi,

Function overrides for the 'goto implementation' operation is now implemented on the 'staging' branch.

So if you go to a function implementation that points to a pure virtual function, it will also search for the implementation(s) in subclasses.

I'm still pondering if I should also do the same for non-pure virtual functions and offer the user a list, or if this should be a separate operation like 'Find function overrides'.

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

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #177 on: October 26, 2016, 05:54:10 pm »
Just pushed fixes and a .cbp for wxWidgets 3.0 support on the 'staging' branch.

Compiling for wxWidgets 3.0 should now work correctly and I'll be continuously testing it, just like I do for wxWidgets 2.8.

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

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Clang CC
« Reply #178 on: October 27, 2016, 11:36:56 am »
honestly: your project files (for windows) are a danger for the commonality. Everywhere hard coded paths (THE OUTPUT IS TO C:\git ????????? honestly??????) ...
i have cleaned up and will make a pull request, but i am not able to run the plugin... Codeblocks gives me errors about symbols not loaded and depwalker shows me unresolved symbols for libclang.dll i thought clang is linked in statically?

[edit:] my problem is that the official build of clang is for msvc and i need a build for mingw...
« Last Edit: October 27, 2016, 01:04:41 pm by BlueHazzard »

Offline yvesdm3000

  • Almost regular
  • **
  • Posts: 225
Re: Clang CC
« Reply #179 on: November 01, 2016, 10:53:38 am »
honestly: your project files (for windows) are a danger for the commonality. Everywhere hard coded paths (THE OUTPUT IS TO C:\git ????????? honestly??????) ...
i have cleaned up and will make a pull request, but i am not able to run the plugin... Codeblocks gives me errors about symbols not loaded and depwalker shows me unresolved symbols for libclang.dll i thought clang is linked in statically?

[edit:] my problem is that the official build of clang is for msvc and i need a build for mingw...
Hi,
No clang is not linked in statically.
Sorry that the project file for windows isn't of high quality yet. Patches are welcome. It is pretty hard for me to test this on windows since that is not my main platform. Please indicate if you are willing to clean up the project file since I don't want to do duplicate work. If not, I'll take a look at it.

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