On Nov 27, 2011, at 7:23 AM, Ted Kremenek wrote:
> 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
>
> Thanks so much,
> Ted
>
> On Nov 27, 2011, at 5:10 AM, unitydeveloper wrote:
>
>> 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
>>
>> On 26 Nov 2011, at 18:00, cfe-dev-request at cs.uiuc.edu wrote:
>>
>>> Send cfe-dev mailing list submissions to
>>> cfe-dev at cs.uiuc.edu
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> or, via email, send a message with subject or body 'help' to
>>> cfe-dev-request at cs.uiuc.edu
>>>
>>> You can reach the person managing the list at
>>> cfe-dev-owner at cs.uiuc.edu
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of cfe-dev digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: how to dump/trace the include path to a previous
>>> definition (Matthieu Monrocq)
>>> 2. Re: how to dump/trace the include path to a previous
>>> definition (Philip Ashmore)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Fri, 25 Nov 2011 19:43:46 +0100
>>> From: Matthieu Monrocq <matthieu.monrocq at gmail.com>
>>> Subject: Re: [cfe-dev] how to dump/trace the include path to a
>>> previous definition
>>> To: Philip Ashmore <contact at philipashmore.com>
>>> Cc: cfe-dev at cs.uiuc.edu
>>> Message-ID:
>>> <CAKE6RfgSsP4Dkr9a8uU3RPsTF9LtDfNkAaQSzYvYgwUMi4x58A at mail.gmail.com>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Le 25 novembre 2011 04:16, Philip Ashmore <contact at philipashmore.com> a
>>> ?crit :
>>>
>>>> Hi there.
>>>>
>>>> Is there a way to get clang to store/dump the include path to previous
>>>> definitions/typedefs?
>>>>
>>>> Saying that A, defined in file B, line C was previously defined in file
>>>> B, line C isn't helpful.
>>>>
>>>> I know, I know, "don't include the same header file twice" but I have
>>>> good reasons to do so.
>>>>
>>>> Details:
>>>>
>>>> I have several projects that use header files to do the "C" equivalent
>>>> of class template definitions.
>>>> The "templates" are things like AVL trees, and the "classes" are
>>>> instantiations of the template with #defines standing in for template
>>>> arguments.
>>>>
>>>> This approach is currently the only way I can get multiple instances of
>>>> the same template into a translation unit without name clashes - I wish
>>>> there was a better way.
>>>>
>>>> Unfortunately this approach isn't without its problems.
>>>>
>>>> My next release will include the project files using "-I\${top_srcdir}"
>>>> instead of "-isystem ${top_srcdir}" and this has uncovered problems now
>>>> that the compiler knows the project include files are not system headers.
>>>>
>>>> The one I'm stumped by is typedef redefinitions caused by multiple
>>>> inclusion from the same include file.
>>>>
>>>> I'm sure a solution to this problem would be of use to others too - I'm
>>>> not the only one who uses tricks like this.
>>>>
>>>> Regards,
>>>> Philip Ashmore
>>>>
>>>
>>> Is there any special reason that you would use:
>>>
>>> #include "mytrick.h"
>>>
>>> Instead of a regular macro invitation with arguments:
>>>
>>> MY_TRICK()
>>>
>>> ?
>>>
>>> Clang would deal with the latter very nicely, especially since Chandler
>>> worked out the macro expansion in diagnostics.
>>>
>>> -- Matthieu
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20111125/e7424fe5/attachment-0001.html
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Fri, 25 Nov 2011 21:06:01 +0000
>>> From: Philip Ashmore <contact at philipashmore.com>
>>> Subject: Re: [cfe-dev] how to dump/trace the include path to a
>>> previous definition
>>> To: Matthieu Monrocq <matthieu.monrocq at gmail.com>, cfe-dev at cs.uiuc.edu
>>> Message-ID: <4ED00339.9060201 at philipashmore.com>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> On 25/11/11 18:43, Matthieu Monrocq wrote:
>>>>
>>>>
>>>> Le 25 novembre 2011 04:16, Philip Ashmore <contact at philipashmore.com
>>>> <mailto:contact at philipashmore.com>>
>>>> a ?crit :
>>>>
>>>> Hi there.
>>>>
>>>> Is there a way to get clang to store/dump the include path to previous
>>>> definitions/typedefs?
>>>>
>>>> Saying that A, defined in file B, line C was previously defined in
>>>> file
>>>> B, line C isn't helpful.
>>>>
>>>> I know, I know, "don't include the same header file twice" but I have
>>>> good reasons to do so.
>>>>
>>>> Details:
>>>>
>>>> I have several projects that use header files to do the "C" equivalent
>>>> of class template definitions.
>>>> The "templates" are things like AVL trees, and the "classes" are
>>>> instantiations of the template with #defines standing in for template
>>>> arguments.
>>>>
>>>> This approach is currently the only way I can get multiple
>>>> instances of
>>>> the same template into a translation unit without name clashes - I
>>>> wish
>>>> there was a better way.
>>>>
>>>> Unfortunately this approach isn't without its problems.
>>>>
>>>> My next release will include the project files using
>>>> "-I\${top_srcdir}"
>>>> instead of "-isystem ${top_srcdir}" and this has uncovered
>>>> problems now
>>>> that the compiler knows the project include files are not system
>>>> headers.
>>>>
>>>> The one I'm stumped by is typedef redefinitions caused by multiple
>>>> inclusion from the same include file.
>>>>
>>>> I'm sure a solution to this problem would be of use to others too
>>>> - I'm
>>>> not the only one who uses tricks like this.
>>>>
>>>> Regards,
>>>> Philip Ashmore
>>>>
>>>>
>>>> Is there any special reason that you would use:
>>>>
>>>> #include "mytrick.h"
>>>>
>>>> Instead of a regular macro invitation with arguments:
>>>>
>>>> MY_TRICK()
>>>>
>>>> ?
>>>>
>>>> Clang would deal with the latter very nicely, especially since
>>>> Chandler worked out the macro expansion in diagnostics.
>>>>
>>>> -- Matthieu
>>>>
>>> Here are a few reasons off the top of my head:
>>> 1. Putting code inside a macro makes debugging almost impossible
>>> 2. some parts of the include file are conditional, surrounded with #if #endif
>>> I'll grant you that macro name munging so that the excluded code is in the "off"
>>> branch, but then we're back to (1)
>>> 3. I reported a bug about a problem with cpp's macro expansion -
>>> "cpp-4.4: incorrect macro expansion when a macro call results in the same macro being called"
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590008
>>>
>>> I know I can do the clang -E trick to examine the preprocessed output, but since clang is
>>> all about useful and descriptive diagnostics, I thought that a check that something being
>>> redefined by the same file/line to prompt a backtrace of the previous definition would save
>>> me and others from the trouble - yet another reason to use clang.
>>>
>>> Philip
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>> End of cfe-dev Digest, Vol 53, Issue 86
>>> ***************************************
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>