[LLVMdev] Optimal settings for parsing and reparsing the translation unit in libclang

don hinton don.hinton at gmx.com
Sun Aug 19 18:39:13 PDT 2012


On Aug 19, 2012, at 19:32, Klemen Forstneric <brucewayne97 at gmail.com> wrote:

> Nope, I parse the first time, and then reparse everytime something changes in my text buffer (because I syntax color based on what libclang gives me). And it worked fine (and fast) with clang_defaultEditingTranslationUnitOptions for clang_parseTranslationUnit and clang_defaultReparseOptions for clang_reparseTranslationUnit. Until I saw that clang_codeCompleteAt doesnt work with anything else than CXTranslationUnit_None.

Well, at least you don't crash. 

I've found that if I try to reload a saved tu file where the underlying source has changed, it'll crash -- so I don't reuse them between runs.

take care...
don

> 
> 
> On Mon, Aug 20, 2012 at 2:01 AM, don hinton <don.hinton at gmx.com> wrote:
> On Aug 19, 2012, at 18:11, Klemen Forstneric <brucewayne97 at gmail.com> wrote:
> 
> > Hey everyone!
> >
> > I'm having trouble finding the optimal performance settings for parsing/reparsing the translation unit. At this moment I'm using CXTranslationUnit_None for both parsing and reparsing the translation unit, because it seems that as soon as I turn on default settings for parse/reparse (clang_defaultEditingTranslationUnitOptions and clang_defaultReparseOptions respectively) code completion stops giving me the right results. Sure I could keep using CXTranslationUnit_None but as soon as I include additional headers to my source file, the whole thing becomes too slow.
> 
> Are you saving the tu then reloading it, or parsing it from scratch everytime?
> 
> >
> > Is this a bug or is this how It's supposed to work? Please give me some guidance.
> >
> > Thanks in advance,
> > Klemen
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120819/bf990ef0/attachment.html>


More information about the llvm-dev mailing list