bug reporting for libclang

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