Cquery vs Clangd

Clang Frontend
#1

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é

#2

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 :slight_smile:
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 :slight_smile:

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

#3

Hi Manuel,

A few relies below.

  • 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 :slight_smile:

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é

#4

Hi Manuel,

A few relies below.

  • 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 :slight_smile:

  • 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 :slight_smile:

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 :slight_smile:

#5

   Hi Manuel,

   A few relies below.

       - 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 :slight_smile:

⚙ D40072 [libclang] Support querying whether a declaration is invalid ⚙ D39903 [libclang] Allow pretty printing declarations
⚙ D41575 [index] Return when DC is null in handleReference

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

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 :slight_smile:

       - 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 :slight_smile:

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 :slight_smile:

   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 :slight_smile:

       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!