(For some reason, it appears clang_codeCompleteAt() is simply dumping all tokens that it knows, instead of using any sort of heuristic search/namespace resolution. I do not know if that is error on my part, or if that is the expected output...)Oops. User error on my part. The location I passed for line/column was 0-index based, however, clang was expecting 1-index based.
git clone https://github.com/alpha0010/ClangLib.git
Btw, when do we get the merge of your cc branch into trunk?From what I can tell, it runs as stable as the trunk (I am using the cc_interface branch as my main code editor). Part of my purpose with testing this Clang plugin is to see if any obvious changes must be made to the interface.
Never understood how clang's CC works in terms of finding symbols outside of local file scope.The way it is set up, Clang essentially compiles the file (into memory), so all of the #includes are resolved and expanded. Searches are done per translation unit, not per file (which does mean I had to do a bit of file trickery in this plugin).
Repository is up.Codehttps://github.com/alpha0010/ClangLib (https://github.com/alpha0010/ClangLib)git clone https://github.com/alpha0010/ClangLib.git
Please copy the attached image into src/devel/share/codeblocks/images/codecompletion/ before testing.
That said, my ideal target is one/two months (which depends a lot on how easy porting the FortranProject turns out to be).
Ubuntu 13.10's clang libs seems to be missing clang-c/Index.h, so I can't build it. Anyone know of a workaround? (Installing clang from source not an option in the near term)The package libclang-3.4-dev has it (libclang-dev also works, but why not use the newer version since it is available?). (Note that in the project file, the search path for it is currently hard coded, so you may have to adapt it to your computer.)
Why don't you just deploy this file with a post build step in the project settings?I was planing to have CCManager provide a default set of icons, so I would end up deleting this from the Clang project later... Not really a valid excuse :) . Just lazy.
Has anyone contacted the fortran maintainer? (I think he has the username darmar)I have not yet; I will send a PM now.
dmoore: Have you tried to install clang-dev or -devel?
Yes. No sign of the needed headers. I will try installing 3.4...Hmm... I found them under /usr/lib/llvm-3.2/include and /usr/lib/llvm-3.4/include respectively.
Yes. No sign of the needed headers. I will try installing 3.4...Hmm... I found them under /usr/lib/llvm-3.2/include and /usr/lib/llvm-3.4/include respectively.
You got a working Clang on Windows? How so?I downloaded Clang for Windows (http://llvm.org/releases/3.4/LLVM-3.4-win32.exe) form here (http://llvm.org/releases/download.html#3.4), installed it, added the proper paths to the project file, and it just worked (which did actually surprise me). Windows .cbp is now committed.
That doesn't seem to have anything like WinAPI headers (or libs) or even C++SL, need to copy those over from MinGW?I've seen that, too - in fact I am monitoring this site. The thing is, you can and have to adjust the compiler config to make use of another compiler that provides those API. If I am not mistaken, this works well with that release for VC, but I doubt it will work reliable for MinGW. What I did was compiling clang itself using MinGW (based on Makefiles created for Code::Blocks using cmake) which ensure ABI compatibility with that compiler. Then you can adjust the compiler settings so they point to exactly this MinGW distribution - and have to add very low-level include folders so it actually FINDS the references. This depends on the standard used, so its really fiddling with settings.
What I did was compiling clang itself using MinGWSadly, wasting days and days on compiling compilers to no avail is something I can't afford any more :(
So basically CLang seems to work, as long as you don't try anything like #include <algorithm> or #include <vector>. It compiles and links int main() { return 0; } lightning fast, too :P. If only it worked for anything else as well...That basically summarises my experience except hat I provided a C library through MinGW but the linker complained anyways.
Well, maybe in 3-4 months. They do seem to be working on getting something usable together.I am waiting ~1,5 years now.
Sadly, wasting days and days on compiling compilers to no avail is something I can't afford any more :(I never compiled compilers before at all, but this one is rather easy, as configuring, adjusting and start compiling takes ~10 minutes and uses Code::Blocks which works on Windows. Otherwise I wouldn't have wasted my time.
I downloaded Clang for Windows (http://llvm.org/releases/3.4/LLVM-3.4-win32.exe) form here (http://llvm.org/releases/download.html#3.4), installed it, added the proper paths to the project file, and it just worked (which did actually surprise me).Oh, sorry, I should have specified. By 'worked' I was referring to linking with this plugin, and providing access to its AST and CC.
The last image is interesting. Can you try to explain how it works and what kind of API do you use?
* 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 (https://github.com/alpha0010/ClangLib/blob/master/clangproxy.cpp#L335).
Yes, that is it.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
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.
(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.
Have you tried the binaries, I think they build them everydayTheir builds don't have WinAPI, nor C++SL. That be the reason why I'd waste hours trying to do a build myself.
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.
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.
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:
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).
[...] 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 (https://github.com/alpha0010/codeblocks_sf/tree/cc_interface) (details here (http://forums.codeblocks.org/index.php/topic,18114.0.html)).
[...] 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 (https://github.com/alpha0010/codeblocks_sf/tree/cc_interface) (details here (http://forums.codeblocks.org/index.php/topic,18114.0.html)).
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?From your LLVM/Clang installation, is 'libclang.dll' (some_path\LLVM\bin\libclang.dll) in the executable's searchable path?
If you want to have some feedback:Feedback is always welcome, thank you. (Though, life is very busy for me right now, so no promises on how soon I will be able to address anything.)
1. In my case there is a huge delay when loading a project (first parsing takes place) and when changing the current active file. Is that a normal behaviour at the current development status?Known problem. Currently, my development on this plugin has been mainly to try to explore the extent of possible functionality that clang provides. I have ignored performance... though, once I try to bring this plugin to more 'daily' use, the next steps will be to increase caching of results, and to move parsing to a separate thread, so as not to block the UI for so long (not done yet due to simplicity).
Binary release (https://github.com/alpha0010/ClangLib/releases/tag/v0.1) available here (https://github.com/alpha0010/ClangLib/releases/download/v0.1/ClangLib_v0.1_20140511_rev9765_win32.7z) for Windows, compatible with nightly build rev9765.Hi, Alpha, very nice work, I have just download both the nightly build and this clanglib binaries, the question is: How to use this plugin?
codeblocks.exe caused an Access Violation at location 62f86c09 in module libclang.dll Reading from location 00000014.
Registers:
eax=00000000 ebx=0000001e ecx=0022f6d0 edx=7b220a2d esi=0022f6c8 edi=075a97b0
eip=62f86c09 esp=0022f568 ebp=0022f760 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
Call stack:
62F86C09 libclang.dll:62F86C09 clang_getInclusions
62447151 clanglib.dll:62447151
6CC41261 wxmsw28u_gcc_cb.dll:6CC41261 _ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_
6CCC436E wxmsw28u_gcc_cb.dll:6CCC436E _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
6CCC47A7 wxmsw28u_gcc_cb.dll:6CCC47A7 _ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent
6CCC4864 wxmsw28u_gcc_cb.dll:6CCC4864 _ZN12wxEvtHandler12ProcessEventER7wxEvent
6CDC9F08 wxmsw28u_gcc_cb.dll:6CDC9F08 _ZN11wxTimerBase6NotifyEv
6CD01CB4 wxmsw28u_gcc_cb.dll:6CD01CB4 _ZN7wxTimer4InitEv
75DBC4E7 USER32.dll:75DBC4E7 gapfnScSendMessage
75DBC5E7 USER32.dll:75DBC5E7 gapfnScSendMessage
75DBCC19 USER32.dll:75DBCC19 gapfnScSendMessage
75DBCC70 USER32.dll:75DBCC70 DispatchMessageW
75DB41EB USER32.dll:75DB41EB IsDialogMessageW
6CCEFD80 wxmsw28u_gcc_cb.dll:6CCEFD80 _ZN11wxEventLoop17PreProcessMessageEP6tagMSG
6CCEF852 wxmsw28u_gcc_cb.dll:6CCEF852 _ZN11wxEventLoop14ProcessMessageEP6tagMSG
6CCEFAEF wxmsw28u_gcc_cb.dll:6CCEFAEF _ZN11wxEventLoop8DispatchEv
Do I need to disable the normal cc plugin?Technically you probably should (because otherwise you are parsing everything twice), however, I do not. The two plugins seem to coexist nicely on my computer.
Q1: How to remove(hide) the tip window, see image shot below, do I need to hit some short-cut key?Currently hardcoded to show warnings and errors, so I guess your two options are: fix the warning, or add -w to your compiler flags (restart C::B probably required). Or patch the plugin :) .
On my system: [...]Does this happen with any project? If it is a specific file, are you able to post a (minimal) code piece that will cause this crash?
Oh, apologies; looks like I never got back to you on this.Hi Alpha!I have successfully compiled the ClangLib plugin but always crash at clang_getInclusions when they start to parse the project.Odd... Did you self-compile everything, or is this linking against a nightly?
Compiled myself with TDM GCC 4.6.1, CB svn 9760, LLVM + Clang 3.3 and your ClangLib plugin.
On small CB projects, ex. c++ Hello World it's working but on projects with wxWidgets always crash.
Do you have a special build steps to compile LLVM with gcc on Windows?
Hi Alpha!Oh, apologies; looks like I never got back to you on this.Hi Alpha!I have successfully compiled the ClangLib plugin but always crash at clang_getInclusions when they start to parse the project.Odd... Did you self-compile everything, or is this linking against a nightly?
Compiled myself with TDM GCC 4.6.1, CB svn 9760, LLVM + Clang 3.3 and your ClangLib plugin.
On small CB projects, ex. c++ Hello World it's working but on projects with wxWidgets always crash.
Do you have a special build steps to compile LLVM with gcc on Windows?
For Windows, I use the prebuilt LLVM/Clang (3.4), and TDM GCC 4.8.1 to compile wxWidgets and Code::Blocks.
My guess from your crash is that clang_parseTranslationUnit() is returning null (which it will do in the case of internal errors so extreme, it cannot recover), and then the null is passed to clang_getInclusions(). Most likely, this is due to a compiler flag (and not your source code itself - clang seems fairly good at handling, or gracefully backing down, on any sort of code I have sent it). Could you post your full compile command line for the project that crashes?
g++.exe -Wextra -Wall -pg -g -pipe -Wno-attributes -Winvalid-pch -include wx_pch.h -fpermissive -finput-charset=ISO-8859-2 -D__GNUWIN32__ -D__WXMSW__ -DwxUSE_UNICODE -DWX_PRECOMP -D__WXDEBUG__ -D__USE_MALLOC -IE:\Dev\C-C++\CodeBlocks\DevPacks\wx\lib\gcc_lib\mswud -IE:\Dev\C-C++\CodeBlocks\DevPacks\wx\include -Ie:\Dev\C-C++\CodeBlocks\DevPacks\litecms2\include -IControls -IE:\Dev\C-C++\CodeBlocks\DevPacks\nvwa\bin\Debug -Ie:\Dev\C-C++\CodeBlocks\DevPacks\nvwa -Ie:\Dev\C-C++\CodeBlocks\DevPacks\debug -Ie:\Dev\C-C++\CodeBlocks\DevPacks\wx\lib\gcc_dll\mswu -c E:\Dev\C-C++\Proiecte\VaanColorPicker\VCPSettings.cpp -o obj\MinGW\Debug_lcms2\VCPSettings.o
This is the command line for g++:Okay, I believe clang is choking on "-finput-charset=ISO-8859-2", could you test: disable clang plugin, remove that build flag, enable clang plugin (probably need to restart C::B).Codeg++.exe -Wextra -Wall -pg -g -pipe -Wno-attributes -Winvalid-pch -include wx_pch.h -fpermissive -finput-charset=ISO-8859-2 -D__GNUWIN32__ -D__WXMSW__ -DwxUSE_UNICODE -DWX_PRECOMP -D__WXDEBUG__ -D__USE_MALLOC -IE:\Dev\C-C++\CodeBlocks\DevPacks\wx\lib\gcc_lib\mswud -IE:\Dev\C-C++\CodeBlocks\DevPacks\wx\include -Ie:\Dev\C-C++\CodeBlocks\DevPacks\litecms2\include -IControls -IE:\Dev\C-C++\CodeBlocks\DevPacks\nvwa\bin\Debug -Ie:\Dev\C-C++\CodeBlocks\DevPacks\nvwa -Ie:\Dev\C-C++\CodeBlocks\DevPacks\debug -Ie:\Dev\C-C++\CodeBlocks\DevPacks\wx\lib\gcc_dll\mswu -c E:\Dev\C-C++\Proiecte\VaanColorPicker\VCPSettings.cpp -o obj\MinGW\Debug_lcms2\VCPSettings.o
The same crash.This is the command line for g++:Okay, I believe clang is choking on "-finput-charset=ISO-8859-2", could you test: disable clang plugin, remove that build flag, enable clang plugin (probably need to restart C::B).Codeg++.exe -Wextra -Wall -pg -g -pipe -Wno-attributes -Winvalid-pch -include wx_pch.h -fpermissive -finput-charset=ISO-8859-2 -D__GNUWIN32__ -D__WXMSW__ -DwxUSE_UNICODE -DWX_PRECOMP -D__WXDEBUG__ -D__USE_MALLOC -IE:\Dev\C-C++\CodeBlocks\DevPacks\wx\lib\gcc_lib\mswud -IE:\Dev\C-C++\CodeBlocks\DevPacks\wx\include -Ie:\Dev\C-C++\CodeBlocks\DevPacks\litecms2\include -IControls -IE:\Dev\C-C++\CodeBlocks\DevPacks\nvwa\bin\Debug -Ie:\Dev\C-C++\CodeBlocks\DevPacks\nvwa -Ie:\Dev\C-C++\CodeBlocks\DevPacks\debug -Ie:\Dev\C-C++\CodeBlocks\DevPacks\wx\lib\gcc_dll\mswu -c E:\Dev\C-C++\Proiecte\VaanColorPicker\VCPSettings.cpp -o obj\MinGW\Debug_lcms2\VCPSettings.o
#0 6970B665 libclang!clang_defaultCodeCompleteOptions() (E:\Dev\C-C++\CodeBlocks\libclang.dll:??)
#1 00000040 ?? () (??:??)
#2 695F749E libclang!clang_defaultCodeCompleteOptions() (E:\Dev\C-C++\CodeBlocks\libclang.dll:??)
#3 ?? ?? () (??:??)
3- The '.' and '->' kicks in for almost everything like 'for./->' 'int./->' 'some_class_name./->' even when typed on their own and the list consists of almost everything too.Hmm, I never noticed it before; I shall be working on resolving that.
- The (parsing?) delay also occurs pretty often when I'm editing headers. When I want to type a new member function, I get a delay of 1 - 2 seconds every 2 characters.Working editing headers disables clang's internal caching ability, so that is why the delay is even more noticeable. (This delay is unacceptable for real work; I am thinking on how to best resolve it.)
[...]I will be looking more in depth to try to reproduce this crash on my machine (probably this weekend, or sooner if time allows). Could you also post (an archive of) a minimal project that causes the crash?
The same crash.
I made a simple wxFrame project and after i added a button on frame and set OnClick event for button... [...]
It sometimes makes C::B unresponsive for some seconds, and a couple of times I've had C::B crash when opening projects.Known issues; this plugin is still in its early stages, and not intended for general use.
When your code is still being written, the errors displayed inside the code take too much room and make readability poor.From my usage, it currently updates too quickly for sane typing, so I think changing the default to a longer timer, or only checking on save, might be better. Also, once there is a settings page, this will become configurable to put messages in tooltips/not display at all.
Also I'd prefer not to have all parameter commas written when I am writing a function.It looked like a good idea at the time :P , though I agree, it mostly just gets in the way (without the ability to tab between parameters, or something).
I unfortunately am currently recovering from a minor surgery, so I am unsure when I will be able to step back into work. Soon hopefully.Don't worry there is no hurry. I just tried the plugin and thoguht it would be nice to give some feedback. But right now just concentrate on recovering ;)
I unfortunately am currently recovering from a minor surgery, so I am unsure when I will be able to step back into work. Soon hopefully.Hopefully you will be recovered soon :).
The Clanglib does not work with last CB svn build (994x+).What exactly is not working? (During my quick test, it built and ran against svn head.)