[cfe-dev] cfe-dev Digest, Vol 53, Issue 89
unitydeveloper
alessandro at runpresto.com
Sun Nov 27 12:01:15 PST 2011
Hi Ted,
thanks very much for your reply.
I have just filed a bug report with an Xcode sample project you guys can use to test.
It's a very basic Cocoa app that lets you open files and lexical highlight them when modifying them.
To reproduce issues 1 and 2 just open any .h or .m file in the project itself.
Is there maybe an older version of clang that may not have those issues?
Xcode itself is pretty good at highlighting, and I assume it uses clang for it.
Assuming this is the case, there must be a way to do proper highlighting… Any advice?
Best,
Alessandro
On 27 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: bug reporting for libclang (Ted Kremenek)
> 2. Re: Implementation of IO2BO Dynamic Checks (Ted Kremenek)
> 3. New comer's problem: library link error of a clang example
> (susangao)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 27 Nov 2011 07:23:19 -0800
> From: Ted Kremenek <kremenek at apple.com>
> Subject: Re: [cfe-dev] bug reporting for libclang
> To: unitydeveloper <alessandro at runpresto.com>
> Cc: Argyrios Kyrtzidis <kyrtzidis at apple.com>, "cfe-dev at cs.uiuc.edu
> Developers" <cfe-dev at cs.uiuc.edu>
> Message-ID: <E114A026-5044-4D3D-81D2-6B937A0CB26F at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 27 Nov 2011 08:59:33 -0800
> From: Ted Kremenek <kremenek at apple.com>
> Subject: Re: [cfe-dev] Implementation of IO2BO Dynamic Checks
> To: Benjamin Schulz <bjs428 at mail.missouri.edu>
> Cc: cfe-dev at cs.uiuc.edu
> Message-ID: <68130779-4105-4A85-97E3-041E883FB6E7 at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> Hi Ben,
>
> I could be mistaken, but I'm not aware of this work (IntPath) being integrated into Clang mainline, nor efforts from the authors to push it into mainline at this time.
>
> There's a general interest in having work like this pushed back to mainline if (a) the quality of the code is up the standard of the codebase and (b) the work will be maintained after the initial check-in.
>
> Cheers,
> Ted
>
> On Nov 22, 2011, at 1:59 PM, Benjamin Schulz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all,
>>
>> I noticed some recent research by Zhang et al on the insertion of
>> dynamic checks for integer-overflow-to-buffer-overflow (IO2BO)
>> vulnerabilities[1]. It looks like Zhang et al's implementation already
>> happens to use the LLVM framework, and I was wondering if any work has
>> been done to incorporate a feature like this into the trunk of Clang.
>>
>> If so, could someone point me to where the code lives in the SVN tree?
>> If not, is anyone out there on the list doing something similar as a
>> side-project?
>>
>> Much thanks,
>>
>> - --Benjamin Schulz
>>
>> * * *
>>
>> [1] Zhang, Chao, Tielie Wang, Tao Wei, Yu Chen, and Wei Zou. "IntPath:
>> Automatically Fix Integer-Overflow-to-Buffer-Overflow Vulnerability at
>> Compile-Time". ESORICS 2010.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJOzBtWAAoJECT8Sbi31ptpuC0IAK2PrMbvJqgNyBx54CdfIb4i
>> Cwqgn1boP9tCB4+KH+jrRj9LaT8ZJmSnx+Nb725HjmhWBCS1mRDtL8qq+s11XMZQ
>> Nyh88Qj+uiPdf6Ok1YKlZOHosg6UNjLoE4twLENFbfU/lqN9baTt9u+Zc0ioaUA1
>> lJZVXrKCifytUKr6Ji0IMs8t4tTsU5XeyTRETisjBj1DruYPy2sZOdWPyqMv6tB0
>> fxVoruSyhj/ZIfNnhzXLJzhO30TJRrCYBsPmp2WyZTenj0HW7VqNqgRkgonDJNOk
>> uOMjFpzfgtHrAxVuyfuldyZJ98kOkXDSaXGPYwxBPnEqU2aEAq6L4/Y4EzBbHew=
>> =+XxK
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 23 Nov 2011 18:46:08 -0800 (PST)
> From: susangao <gaoshuang at gmail.com>
> Subject: [cfe-dev] New comer's problem: library link error of a clang
> example
> To: cfe-dev at cs.uiuc.edu
> Message-ID: <1322102768428-3532706.post at n3.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi all,
>
> I just started learning clang example. I tried to build an example (as
> attached .cpp and Makefile), and get the following link errors:
>
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:30: undefined
> reference to `clang::CompilerInstance::CompilerInsta
> http://clang-developers.42468.n3.nabble.com/file/n3532706/test.tar.gz
> test.tar.gz nce()'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:33: undefined
> reference to `clang::CompilerInstance::createDiagnostics(int, char const*
> const*, clang::DiagnosticConsumer*, bool, bool)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:35: undefined
> reference to
> `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char
> const* const*, char const* const*, clang::DiagnosticsEngine&)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:37: undefined
> reference to `clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&,
> clang::TargetOptions&)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:37: undefined
> reference to `clang::CompilerInstance::setTarget(clang::TargetInfo*)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:39: undefined
> reference to `clang::CompilerInstance::createFileManager()'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:40: undefined
> reference to
> `clang::CompilerInstance::createSourceManager(clang::FileManager&)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:41: undefined
> reference to `clang::CompilerInstance::createPreprocessor()'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:42: undefined
> reference to `clang::CompilerInstance::createASTContext()'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:43: undefined
> reference to `clang::CompilerInstance::setASTConsumer(clang::ASTConsumer*)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:45: undefined
> reference to
> `clang::CompilerInstance::createSema(clang::TranslationUnitKind,
> clang::CodeCompleteConsumer*)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:47: undefined
> reference to
> `clang::CompilerInstance::InitializeSourceManager(llvm::StringRef)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:48: undefined
> reference to `clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*,
> clang::ASTContext&, bool, clang::TranslationUnitKind,
> clang::CodeCompleteConsumer*)'
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:50: undefined
> reference to `clang::CompilerInstance::~CompilerInstance()'
> /tmp/ccqBn324.o: In function `ASTConsumer':
> /nfs/susangao/llvm-root/llvm/tools/clang/include/clang/AST/ASTConsumer.h:39:
> undefined reference to `vtable for clang::ASTConsumer'
> /tmp/ccqBn324.o: In function `~ASTConsumer':
> /nfs/susangao/llvm-root/llvm/tools/clang/include/clang/AST/ASTConsumer.h:41:
> undefined reference to `vtable for clang::ASTConsumer'
> /tmp/ccqBn324.o: In function
> `llvm::raw_ostream::operator<<(llvm::StringRef)':
> /nfs/susangao/llvm-root/llvm/include/llvm/Support/raw_ostream.h:160:
> undefined reference to `llvm::raw_ostream::write(char const*, unsigned
> long)'
> /tmp/ccqBn324.o: In function
> `llvm::raw_ostream::operator<<(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&)':
> /nfs/susangao/llvm-root/llvm/include/llvm/Support/raw_ostream.h:176:
> undefined reference to `llvm::raw_ostream::write(char const*, unsigned
> long)'
> /tmp/ccqBn324.o: In function `clang::NamedDecl::getNameAsString() const':
> /nfs/susangao/llvm-root/llvm/tools/clang/include/clang/AST/Decl.h:135:
> undefined reference to `clang::DeclarationName::getAsString() const'
> /tmp/ccqBn324.o: In function
> `PrintFunctionsConsumer::HandleTopLevelDecl(clang::DeclGroupRef)':
> /nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:21: undefined
> reference to `llvm::errs()'
> /tmp/ccqBn324.o:(.data.rel.ro._ZTV22PrintFunctionsConsumer[vtable for
> PrintFunctionsConsumer]+0x30): undefined reference to
> `clang::ASTConsumer::HandleInterestingDecl(clang::DeclGroupRef)'
> /tmp/ccqBn324.o:(.data.rel.ro._ZTV22PrintFunctionsConsumer[vtable for
> PrintFunctionsConsumer]+0x48): undefined reference to
> `clang::ASTConsumer::HandleTopLevelDeclInObjCContainer(clang::DeclGroupRef)'
> collect2: ld returned 1 exit status
> make: *** [all] Error 1
>
>
> Would you please help me to know what causes this link error?
>
> The code of llvm and clang are checked out from trunk.
>
> APPRECIATE!
>
> Susan
>
>
> --
> View this message in context: http://clang-developers.42468.n3.nabble.com/New-comer-s-problem-library-link-error-of-a-clang-example-tp3532706p3532706.html
> Sent from the Clang Developers mailing list archive at Nabble.com.
>
>
> ------------------------------
>
> _______________________________________________
> 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 89
> ***************************************
More information about the cfe-dev
mailing list