Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] LLVM Project Blog: A path forward for an LLVM toolchain on Windows

libclang has many configuration options, e.g. it had a now-deprecated option CXTranslationUnit_SkipFunctionBodies when it would ignore function bodies (actually, I found it enough for "rough" index - so you know if the symbol is even visible in particular TU. And every indexer worker would be a compiler - so it is easily parallelizable. 

Note that libclang can provide you lists of completions - and it is fairly fast at it, even though it essentially reparses the TU. It has some optimizations like "precompiling" the headers for the edited files.


IMHO, the best showcase of the libclang is Xcode though YouCompleteMe for vim and SublimeClang can be used to try it out as well.

On Sep 11, 2013, at 6:45 PM, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:

Clang's parsing is indeed significantly slower than the CDT one, on order of 5-6 seconds for a typical source file of few hundred lines. Indexing would be particularly sensitive to parsing slowness since it would bring us back to the days of full indexer. One possible solution to this problem is parsing of many source files in parallel.

-sergey


On Wed, Sep 11, 2013 at 6:41 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
On 13-09-11 9:22 PM, "Nathan Ridge" <zeratul976@xxxxxxxxxxx> wrote:

>> CDT would have to switch to Clang's representation of AST. The AST
>> could still be represented by Java objects. Clang parser (probably in a
>>
>> separate process to protect against memory leaks) would serialize its
>> representation of AST and CDT would deserialize it to Java. Converting
>> Clang's AST to the current CDT AST representation is probably not
>> practical. Changing CDT to a different AST representation is a massive
>> undertaking that would touch a lot of code, both in core and in UI.
>>
>> A potential showstopper for the whole plan is existence of such
>> features of Clang bindings that would not allow index bindings to
>> implement the same set of interfaces as the AST bindings. I don't know
>> whether such features exist or not.
>
>Would the distinction between AST and index bindings still need
>to exist in this hypothetical design? As far as I'm aware,
>clang's AST is for the whole translation unit, i.e. it includes
>information about included header files.

The bindings are really for cross translation unit links, for example,
find references which walks the AST Name to it's binding then to the
binding's list of reference AST names. So even if the AST is complete,
you'd still need an index and it's bindings.

But that brings up the point I fear. Right now we skip headers when
indexing. The speedup we got from that was immense. Unless you set up
precompiled headers, I don't think we could get that speedup out of Clang.
But I may be wrong.

Doug.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top