Hi there,
first of all please excuse me if this is not the right place for bug reporting and be so kind to redirect me to the apposite place.
I am using lib clang ( clang version 3.1 (trunk 144457) ) to build a code editor on OSX.
It works pretty well with objective c files ( I didn't test it with C/C++/ObjC++ yet ). I noticed two quite strange behaviours though:
1) when I type a single column ( ':' ) character inside the implementation of a class in an objective-C (.m) file, clang_reparseTranslationUnit() sends a signal and terminates the program. I can send the source code and instructions to reproduce the bug if needed.
2) the clang_reparseTranslationUnit() seems to be much much faster on .m files than on .h files, so much that live lexical colouring (using only clang_tokenize(), not even clang_annotateTokens() )is very slow on .h files, while it easily keeps up with my typing speed with a much longer .m file that includes that very same .h file.
Is there any special procedure for speeding the parsing/tokenizing of .h files up?
Thank you very much,
Alessandro Pistocchi
Hi Alessandro,
This is the right place to raise awareness of such issues.
#1 sounds like a general crash issue in the frontend. That's a general problem that just needs to be fixed. Please file bug report for #1 at:
http://llvm.org/bugs/
and please email the list with the Problem Report #.
Without more information, I'm not sure if #2 is a bug or a general performance issue that needs to be improved. I think it possibly depends on what is being pulled in by your .h file, and I'm not certain how libclang generates precompiled preambles for arbitrary .h files. Can you provide a bit more information on what exactly you are doing in #2? That will help us determine if you are using the API's correctly or if this really is a major performance bug (my suspicion is the latter).
Thanks so much,
Ted
Hi Alessandro,
This is the right place to raise awareness of such issues.
#1 sounds like a general crash issue in the frontend. That's a general problem that just needs to be fixed. Please file bug report for #1 at:
http://llvm.org/bugs/
and please email the list with the Problem Report #.
Without more information, I'm not sure if #2 is a bug or a general performance issue that needs to be improved. I think it possibly depends on what is being pulled in by your .h file, and I'm not certain how libclang generates precompiled preambles for arbitrary .h files. Can you provide a bit more information on what exactly you are doing in #2? That will help us determine if you are using the API's correctly or if this really is a major performance bug (my suspicion is the latter).
About 2):
The main issue is that reparseTranslationUnit is optimizing the case where you are editing the *main* file. Let's say you have this setup:
MyFile.m -> includes headers + MyFile.h
If you are editing "MyFile.h", and you are doing clang_reparseTranslationUnit([MyFile.m]), you end up doing a full parse + precompiled preamble production, because headers included by MyFile.m, changed.
A way to address this is to treat "MyFile.h" as a main file, that is get a translation unit out of [-x objective-c <rest-of-args> MyFile.h] and use clang_reparseTranslationUnit([MyFile.h]) when editing MyFile.h.
Probably this is better to initiate when the user makes changes to MyFile.h, not just to syntax-highlight it (when just browsing).
I see no easy way to optimize MyFile.h editing automatically via reparsing MyFile.m, without introducing some API change to allow the client to be explicit that a specific header is getting edited.
This would enable the optimization as I mentioned it, but I don't see much advantage compared to the client doing clang_reparseTranslationUnit([MyFile.h]) directly, thus having better control on in-memory ASTs and without so much behind-the-scenes-magic.
-Argyrios