[cfe-dev] bug reporting for libclang
Ted Kremenek
kremenek at apple.com
Sun Nov 27 07:23:19 PST 2011
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
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
More information about the cfe-dev
mailing list