Cquery vs Clangd

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Cquery vs Clangd

Hans Wennborg via cfe-dev

Hello,


I would like to discuss Cquery [1] in the light of the current development of Clangd. Both tools implement the Language Server Protocol for C/C++. Cquery seems to be picking up a lot of features which users are interested in. Some differences with Clangd are that it uses libclang and it is developed on Github outside of the LLVM/Clang tree. Perhaps that Clangd has the advantage of having more visibility as it is hosted within the Clang community and has healthy (long term??) development activity. But being out of tree, Cquery also has some flexibility in reusing more third-party library and features are rapidly being prototyped.


With that said, should we make an effort to bridge the two projects?

I would very much like to hear your thoughts on Cquery, especially from fellow Clangd developers.


[1] https://github.com/cquery-project/cquery



Best Regards,

Marc-André



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cquery vs Clangd

Hans Wennborg via cfe-dev
On Wed, Feb 28, 2018 at 11:40 PM Marc-André Laperle via cfe-dev <[hidden email]> wrote:

Hello,


I would like to discuss Cquery [1] in the light of the current development of Clangd. Both tools implement the Language Server Protocol for C/C++. Cquery seems to be picking up a lot of features which users are interested in. Some differences with Clangd are that it uses libclang and it is developed on Github outside of the LLVM/Clang tree. Perhaps that Clangd has the advantage of having more visibility as it is hosted within the Clang community and has healthy (long term??) development activity. But being out of tree, Cquery also has some flexibility in reusing more third-party library and features are rapidly being prototyped.


With that said, should we make an effort to bridge the two projects?


I don't think either side will be really interested in this - there are pretty different fundamental approaches to the two projects.
 

I would very much like to hear your thoughts on Cquery, especially from fellow Clangd developers.


Competition is good :)
Clangd has made some architectural choices that are fundamentally playing a more long-term game, so it's not surprising that cquery is leading with features.
The big differences are:
- 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
- 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
- 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 :)

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.

Cheers,
/Manuel

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cquery vs Clangd

Hans Wennborg via cfe-dev
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?

- 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.

- 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.


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é

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cquery vs Clangd

Hans Wennborg via cfe-dev
On Thu, Mar 1, 2018 at 7:50 PM Marc-André Laperle <[hidden email]> 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.
 
- 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 :)
 
- 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.

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é

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cquery vs Clangd

Hans Wennborg 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 <
>[hidden email]> 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!


--
宋方睿
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev