[cfe-dev] Cquery vs Clangd

[Fāng-ruì Sòng via cfe-dev]

On 2018-03-02, Manuel Klimek via cfe-dev wrote:
>On Thu, Mar 1, 2018 at 7:50 PM Marc-André Laperle <
>marc-andre.laperle at ericsson.com> wrote:
>
>    Hi Manuel,
>
>    A few relies below.
>
>    On Thu, 2018-03-01 at 13:24 +0000, Manuel Klimek wrote:
>
>        - cquery is based on libclang, while clangd directly works with the AST
>        and provides a non-LSP C++ interface to be integrated as service in
>        larger environments - this lets clagnd work in places where libclang is
>        hard to integrate
>
>    Would that C++ interface be usable for out-of-tree projects? I guess one
>    would simply link to libclangDaemon?
>
>Correct.

I also hope the review mechanism will be more friendly to casual
contributors :)

https://reviews.llvm.org/D40072 https://reviews.llvm.org/D39903
https://reviews.llvm.org/D41575

Look how nik (Qt Creator clang plugin maintainer) desperately begged for
reviewing :(

Hope clangd can be a better replacement of libclang, which kdevelop,
ycmd, rtags, ... and many other projects depend on.

Also hope -index-store-path can change the world :)

>        - clangd wants to integrate with other folks in the community on
>        indexing interfaces and mechanisms that provide a platform for tools to
>        work on; while there is also some prototyping, a lot of work goes into
>        designing the right system
>        - clangd puts scale and performance first; for very very large code
>        bases (significantly larger than chromium), this is a precondition, and
>        (together with the previous item) why we don't have a global index yet
>
>    I think cquery puts those two first but it sounds like you have even more
>    agressive requirements.
>
>Unfortunately, yep :)

I believe C++ interface is a more sustainable long-term approach.
But cquery is sufficient for most projects (Chrome, LLVM, Linux kernel,
... which are considered by most people "large projects").

>
>        - clangd work currently focuses on making code completion really good,
>        so quite a bit of work has gone into how to split the preamble and
>        making completion results better (which also benefits cquery \o/)
>
>        The hope is that clangd at some point will catch up with cquery, but as
>        those things go, in the end they will probably have slightly different
>        trade-offs, so some folks will use one while others use the other. In
>        principle that's the nice thing about the LSP; competition is now
>        possible :)
>
>    Yeah, clients can adopt one of the other pretty easily (well maybe without
>    extension support). I think it's good to understand the different
>    trade-offs and compare the different goals so that potential contributors
>    can decide where to focus their work.

The feature I missed so much is cross references, and I felt really sad
to see that feature is not prioritized. (I am new to LLVM and I need to
get into it)

A rough figure about cquery: loading index files for llvm+clang+extra+lld (715MiB)
takes 50s on a laptop and 7s on a workstation.

>
>Yep. I'd say if one wants to contribute to continuing to build up a platform
>for C++ tooling based on clang, get involved in clangd (I believe this is
>specifically a non-goal for cquery); if one wants to get new useful features as
>fast as possible, cquery is a better place, and the clangd code reviews will
>likely turn out to be a source of frustration, as it often involves getting
>consensus across a range of people from different companies :)
>
>        For everyone interested, come join the talk on clangd at the Euro LLVM
>        in Bristol; that talk will include a more detailed comparison between
>        the two approaches.
>
>    That sounds very good. I'll be there!
>
>    Thank you for your time,
>    Marc-André
>

Thank you!


-- 
宋方睿