Author Topic: Clang based CC, new CC interface  (Read 41109 times)

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1510
Re: Clang based CC, new CC interface
« Reply #30 on: January 30, 2014, 06:10:55 am »
* Which docstring formats are you able to highlight code for? (What tool are you using to do the highlighting?)
Maybe it would have been better to try to use a hidden Scintilla control, but to simplify things, I wrote a pseudo-lexer.

The last image is interesting. Can you try to explain how it works and what kind of API do you use?
Looks like just an editor hook, then uses wxScintilla annotations:
See, esp. DiagnoseEd, in https://github.com/alpha0010/ClangLib/commit/6a0c09cf1cd39448d6fa6d022afd9f3a0bed6ebb#diff-2c47c86d730d3c95d68ec3fa39ad7e7bR719
Yes, that is it.
100% should be part of the SDK...
Hmm... I will see if I can figure out a good way to do that.
Does clang provide both CC info + errors/warnings info with a single compile/parse?
Essentially yes.  Also, when working on the root source file of a translation unit (the .cpp), each update after the first parse is significantly faster because headers included at the top have their processed version cached.

With reference to performance, while working in a single editor, this plugin works well.  However, the initialization of each new editor (a source file, not a header) can take 2-5 seconds under Linux, and upwards of 20-30 seconds with Windows (at some point, I will switch this to run in a background thread).  Also, because libclang is organized by translation units, each of these takes 50-150 MB memory.  (Of note, in this plugin, some of the files include Code::Blocks' PCH, and some do not.  The files that do not use it are nearly instantaneous to initialize.)
From my testing, Clang's comment parser seems to have some issues under Linux, and on Windows, often completely fails to return anything (although, that might be error on my part, I am not sure).

(btw, you can also use the README.md or README.rst to embed screen shots  on the github page using a dir in your repo to place the images. Nice feature of github IMO)
Thanks, I will look into that.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Clang based CC, new CC interface
« Reply #31 on: February 07, 2014, 10:38:36 pm »
So, although I should have known better, I wasted the day trying to get Clang-SVN under Windows working. Turned out it is the typical Unix-like open source shit that you expect. Why does everything that you get for free suck so much?

Install prerequisites, configure, and make. Yeah right. Python is a prerequisite for running the test suite. Of course you don't want to run the test suite, but make will fail with "python version > 2.5 required"  if you don't have Python installed. So you install Python version 3.3, and guess what, now make fails with "invalid syntax".
Searching the web for the exact error gives a solution: "Yeah, print is a function in python 3.x now, you will need the latest 2.x version".

Great. Fuck you.

Using vanilla MinGW or MinGW-TDM, configure works fine, but the build fails after 3-4 seconds because off_t is not defined (which is, of course, total bollocks).

So you install Python 2.7 and a MinGW-w64 based compiler, and behold, it configures and builds.

In fact, it builds every darn architecture that LLVM supports, which only takes like 2 hours. So you reconfigure with --enable-targets. No matter what you choose, you get a "cannot determine triplet" error. Fuck you, again.

So you reconfigure again, and rebuild all that shit. The build process has no way of running without the test suite. Anything but "all" fails, and "all" runs the test suite. Further, make hangs when you call it with -j, great. Single-threaded builds in 2014. Fuck you, again.
Surprisingly, it indeed -- finally -- generates a working 460MB compiler. Except there are no C++ or C++11 headers.

So you reconfigure for C++11 support (which you have to specify explicitly!), and guess what. It fails because i386 is not supported under 10.4 and under OSX. The fuck, what?

I'm building a Windows compiler under Windows, using a Windows compiler, targetting Windows. What do I care if i386 is supported under OSX?

EDIT:
Interesting. Looking at the SVN log, I find an entry from earlier today "Try to unbreak MinGW build". So apparently this is a known problem. Well, I'll give it another try next weekend.
« Last Edit: February 07, 2014, 10:50:09 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5011
Re: Clang based CC, new CC interface
« Reply #32 on: February 07, 2014, 11:24:47 pm »
I feel your pain Thomas, I have suffered these things too.
And what is really frustrating these clang guys go shouting all over the world how nice their compiler is a, how much better the gcc and so on. Maybe that is true, but actually as long as they don't make it usable, the only thing they have created is a big piece of shit. I really hope that one day some guy over there really uses his brain instead of their self proclaimed "oh so good compiler"  story.

But in the meantime they ship OS-X with even super old gcc, avoiding people to use gcc on their lovely overpriced mac books.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10186
Re: Clang based CC, new CC interface
« Reply #33 on: February 07, 2014, 11:40:16 pm »
Thomas:
1. Have you reported this problems to clang devs, no point shouting here:)
2. Have you tried the binaries, I think they build them everyday

Killerbot:
You can use newer gcc using macports as far as I know, but they are not 100% compatible :)
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1442
    • CenizaSOFT
Re: Clang based CC, new CC interface
« Reply #34 on: February 08, 2014, 09:25:38 pm »
Just for the record.

The reason why Apple stopped shipping and using newer versions of GCC is because of their current license (GPL3), same reason why they had to drop samba and roll out their own substitute.

As for LLVM and Clang, their main platform is OS X (more like BSD in general, since FreeBSD also decided to drop GCC and move to Clang/LLVM). Linux, being related to Unix and BSD, can, of course, more easily get Clang/LLVM working. Windows, as usual, is the outsider (however popular) when it comes to standards (what Microsoft managed to implement of POSIX is, at its best, laughable).

What I find kind of ironic is the eagerness to bash on Clang/LLVM for its poor support for Windows, when Code::Blocks itself (and wxWidgets for that matter) is in a rather sorry state when it comes to OS X support. The interesting thing is that both projects share the same reason for it: lack of community support and contributions for a specific platform.

By the way, I thought Eranif managed to get Clang working for his code-completion in CodeLite years ago, or am I getting confused? If so, he may be the best guy to ask about it.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Clang based CC, new CC interface
« Reply #35 on: February 09, 2014, 01:28:28 pm »
Have you tried the binaries, I think they build them everyday
Their builds don't have WinAPI, nor C++SL. That be the reason why I'd waste hours trying to do a build myself.

When you do your own build, you can either use CLang's libc++ which is a sooooo much better alternative to GCC's, or have the build process incorporate the existing host standard library from your.

Except of course, neither one works.

Telling configure to use CLang's lib results in an immediate abort (because it passes some unknown commandline option to GCC), and using the host's library "works" except it later turns out that the compiler doesn't have it. Now the obvious solution would be to first bootstrap a half-working CLang without working standard library (which nevertheless understands that command line switch!), and then build a fully functional version from that. Except of course you can't build CLang without a working standard library...

Quote
Have you reported this problems to clang devs, no point shouting here:)
To what avail? Those things must be bloody evident to them. Surely I'm not the first person in the world writing a program that contains #include <algorithm>. Surely I'm not the first to try this with CLang either. They must be aware that it doesn't work.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Clang based CC, new CC interface
« Reply #36 on: February 09, 2014, 01:56:06 pm »
As for LLVM and Clang, their main platform is OS X (more like BSD in general, since FreeBSD also decided to drop GCC and move to Clang/LLVM). Linux, being related to Unix and BSD, can, of course, more easily get Clang/LLVM working. Windows, as usual, is the outsider (however popular) when it comes to standards (what Microsoft managed to implement of POSIX is, at its best, laughable).
This is not Microsoft's fault, however. It is the typical BSD/Linux/Unix shit. Programs must be super portable to run on every system that is 67 years old, with a processor that you can only find in a museum. And configure does that, isn't it just great. Except the software fails to build on the most mainstream system because the software is not written properly, but using that configure crap.
This isn't a symptom particular to CLang. It's the same with GCC and its prerequisites as well. If you try to build GMP, you get this configure error about some typedef not having the correct size. If you just comment out the stupefied line that assumes sizeof(long) == 8, everything works perfect. Now, thing is, without this "super smart portable" shit, it would work much better.

Quote
What I find kind of ironic is the eagerness to bash on Clang/LLVM for its poor support for Windows, when Code::Blocks itself (and wxWidgets for that matter) is in a rather sorry state when it comes to OS X support. The interesting thing is that both projects share the same reason for it: lack of community support and contributions for a specific platform.
There are some notable differences, though:
  • This is a more or less hobby-founded project, not backed by a company the size of Apple. Do we even have one single full-time developer in our team? I think not.
  • C::B actually builds and runs with two clicks on all the most important systems. Except, of course, Apple. Welcome back in the 1990s when I tried to convince everybody around me that it wasn't my Mac's fault that it couldn't properly read Windows disks and Word documents (or any document from anything not Apple, for that matter). Of course that was because everybody else sucked, not Apple.
  • While C::B has a lot of annoying issues (many of which come from the toolkit that we use) it nevertheless works more or less least acceptably for 90% of everything I've ever done, and despite annoyances still gets the job done in 9.5 out of the remaining 10%.
  • We don't claim that Code::Blocks is the greatest thing since the invention of the wheel.

Quote
By the way, I thought Eranif managed to get Clang working for his code-completion in CodeLite years ago, or am I getting confused? If so, he may be the best guy to ask about it.
I have Clang working as far as that's concerned too. Reading closely helps understanding the issue. Getting the support lib to compile (or the whole compiler suite) isn't the issue. The problem is getting a compiler that works with C++ (or Windows).
I have a perfectly working compiler for 10 or 12 different architectures with perfectly working tools and support libs. Except no single C++ header or WinAPI header (or lib) is included, nor is there a way (at least not documented) of configuring it so it will look for C++ headers in some other system path and compiling C++ will work.
« Last Edit: February 09, 2014, 01:57:39 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Clang based CC, new CC interface
« Reply #37 on: February 09, 2014, 09:36:57 pm »
In the mean time, it seems like I've managed to do a build of an almost-working C++ compiler, which borrows the missing headers from an existing MinGW-w64 installation ("borrows" means that it looks in the other compiler's install directory, it remains to be seen how ABI compatibility will play with libs).

At least a minimum compileable C++11 example seems to compile fine. Including <algorithm> and <memory> works as well as including <windows>, further creating a unique_ptr<int> works.

On the downside, CLang fails executing its unit test suite on all std::mutex test cases. Which basically means it's a kind-of working C++11 compiler without thread support (depending on another install). Still not great, but at least getting close to something that works.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4942
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Clang based CC, new CC interface
« Reply #38 on: February 19, 2014, 03:42:43 am »
See what other Open Source/Free IDE's plan on Clang:

1, Qt Creator and Clang | Qt Blog, I notice that clang can even support multiply PCHs, not the single one as GCC.

2, [Qt-creator] Future of Qt Creator's C++ parsing after their discussions [Qt-creator] QtCreator C++ code parser and clang integration status.

3, Kate/KDevelop Sprint 2014: Let There Be Clang | Milian Wolff

4, CodeLitealready integrate Clang code completion.

5, a Clang based on-line code browser, see an example: Parser.cpp [llvm/tools/clang/lib/Parse/Parser.cpp] - Woboq Code Browser, hover the mouse on the function names, you will see every thing, it is free for non-commerical project.

6, (new added), Clang Developers - Clang-based indexer and code navigator, it's demo can be seen SourceWeb


PS: Roberto Raggi, the author of the C++ parser in QtCreator and Kdevelop are now developing another parser from scratch, see: cplusplus, he try to create a new tool as alternative of clang? (he posted here in Cool stuff! about the Qt)
« Last Edit: February 19, 2014, 04:26:12 am by ollydbg »
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 Meiner

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Clang based CC, new CC interface
« Reply #39 on: February 28, 2014, 12:00:47 pm »
I'm very happy that there is some progress in the development of a new clang-based CC-Plugin, thanks for that.

I tried to compile the source code yesterday, but I get some weired errors. Basically classes like wxStringVec, CCToken, CCProviderStatus and CCCallTip seem not to be in scope (include paths, etc. are pointing to the right locations from my point of view). I can't figure out in which files these classes are originally located, so I'm not able to fix this error at the moment. I'd appreciate some hints what I'm doing wrong.
« Last Edit: February 28, 2014, 12:05:49 pm by Meiner »

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1510
Re: Clang based CC, new CC interface
« Reply #40 on: February 28, 2014, 04:46:46 pm »
[...] Basically classes like wxStringVec, CCToken, CCProviderStatus and CCCallTip seem not to be in scope [...]
It sounds like you are compiling against Code::Blocks trunk, which will not work.  I am developing this plugin against the cc_interface branch (details here).

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Clang based CC, new CC interface
« Reply #41 on: February 28, 2014, 06:03:43 pm »
Do you plan on releasing some nightly or binary or something off this branch? That looks cool and I really like to test it! Btw I tried building myself without success because of reasons I have no idea. ;)

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1510
Re: Clang based CC, new CC interface
« Reply #42 on: February 28, 2014, 07:44:58 pm »
An 'official' nightly of the cc_interface branch will likely come soon (this is in internal discussion).  Once that is out, I plan to try packaging a binary of this plugin.

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: Clang based CC, new CC interface
« Reply #43 on: February 28, 2014, 08:46:46 pm »
Alpha, you are doing a great job with that branch, I'm very impatient to ues CB with the code completion provided by clang. Keep the good work, and many thanks !
Kernel Extremist - PedroM power

Offline Meiner

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Clang based CC, new CC interface
« Reply #44 on: March 01, 2014, 12:01:47 pm »
[...] Basically classes like wxStringVec, CCToken, CCProviderStatus and CCCallTip seem not to be in scope [...]
It sounds like you are compiling against Code::Blocks trunk, which will not work.  I am developing this plugin against the cc_interface branch (details here).

Yes, absolutely right, I didn't see the CC-Branch. I'll try to compile it once again, but I'm excited to hear that there may be an (official/inofficial) release in the near future.


EDIT: I have one further question about the build process. I managed it to build the cc-branch and the clanglib plugin against the cc-branch's source code, but starting (compiled) CB leads to the error message: "One or more plugin could not be loaded........clanglib.dll", because of missing symbols. Is there something more I have to do?
« Last Edit: March 01, 2014, 06:40:32 pm by Meiner »