[cfe-dev] bug reporting for libclang

[unitydeveloper]

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
> ***************************************