Hacker News Reader

Comment by snowAbstraction | Hacker News Reader

Is this like https://github.com/Andersbakken/rtags but for vscode?

Any key differences?

For one thing, it sounds like it implements the Language Server protocol, which will make it usable for other IDEs and text editors with support for this protocol (a quickly growing list.)

Not aware of Rtags but I'll assume it's similar to the omnipresent C tags but with an actual C++ parser. If that's the case, in theory cquery is a lot more powerful; it would include the symbol indexing of Rtags but also code refactoring tools ("fixits",) fully aware context-sensitive auto-complete, ability to detect dead code (i.e. #if 0 or #ifndef _WIN32) and support for the type hierarchy. Some of that stuff is definitely not supported by LSP so I imagine it's custom stuff for VSCode only.

All in all, it sounds like it would provide most of the IDE experience to VS Code. The only annoying part would be that you'll have to extract the compile flags from your build system yourself, but that's not usually too big of a deal.

rtags is also using libclang for parsing, fixits, etc.

Here is a demo of rtags can do with a proper emacs setup: CppCon 2015: Atila Neves "Emacs as a C++ IDE" https://youtu.be/5FQwQ0QWBTU

edit: Comment above has updated with more information, making this reply redundant. :)

One interesting thing that rtags does is provide a gcc/clang wrapper script. You make symlinks to it called cc/c++/gcc/g++/etc. in a folder that's in PATH ahead of wherever gcc/clang proper live. When invoked, the script submits an appropriate tags job to the rtags server, complete with compile flags actually used, then passes the command line on to the appropriate tool so that the compile actually gets done.

So quite often you won't need to do anything. (If you use CMake, you will have to rebuild your Ninja/make files after first setting this up.)

I didn't find rtags perfect. There were a few files that it simply never seemed to create tags for, and the rtags setup is complicated enough that I couldn't quickly figure out why, so I just put up with it. But when it works, it works very well...

(This sort of thing seems to be par for the course with this kind of tool. I've seen a number of people complain about how terrible Visual Studio's code browsing is, for example, but it's been a long time since I've had a problem with it...)

Rtags is great for code browsing, but completion is slow and dumb.

I found it fine once I'd set it up to do completion only by request, so I'd know that I might have to wait. The default, whereby it tries to pop up as you type, was absolutely maddening...

> All in all, it sounds like it would provide most of the IDE experience to VS Code. The only annoying part would be that you'll have to extract the compile flags from your build system yourself, but that's not usually too big of a deal.

This can be done similar to what rtags does (hooking into gcc/clang invocations). Alternatively if you use ninja this relatively simple by generating a compile_commands.json file.

    ninja -C out/Release -t compdb cxx cc > compile_commands.json

My eventual plan is to automate compile_commands.json generation if using ninja, so cquery is install and go.

I tried using rtags before developing cquery, but found it did not perform well enough for Chrome when doing a huge number of semantic operations (I was hacking in support for code lens). I spent some time trying to figure out if it code be fixed but I believe it would have been too large of an architectural change.

- cquery interacts with an editor via the language server protocol, letting it work with any editor with relatively minimal work - cquery handles larger repositories better (ie, indexing all of Chrome takes 20-30 minutes on a high-end workstation) - cquery responds to semantic requests within 10ms or so

There are some other differences but those are related to the features implemented, ie, cquery supports code lens.

I'm not sure how code completion is in rtags, but I've spent a fair amount of time making it work as fast as possible in cquery. There is quite a bit of caching built on-top of the clang API which often makes it feel instantaneous.

I've been happy user of ycmd+rtags tandem for a couple of years. A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too). This allows me to do develop on my weak 4-core laptop and offload indexing to fast 32-core workstation.

Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.

Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).

> A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too).

I have a similar use case in mind, so I'm planning on trying to get this working by writing a simple script that proxies language server messages over SSH/TCP. Ideally it should work with any language server.

> Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.

Yea, it is amazing how big of a difference the architecture around indexing makes - any sort of global lock/shared state really hurts performance. I spent a significant amount of time finding the right architecture to make each index job as independent as possible. Most of the design decisions in cquery are oriented towards either latency or throughput at the cost of things like memory and total system load (I've since reduced memory usage, but at one point cquery used 30gb after indexing Chrome - now it is around 5gb).

> Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).

I'd like to see cquery support in vim as well using a vim LSP implementation :). But yes, I agree with you - cquery makes me want to continue using C++ over Rust simply because the tooling works a lot better.

> I have a similar use case in mind, so I'm planning on trying to get this working by writing a simple script that proxies language server messages over SSH/TCP. Ideally it should work with any language server.

I think I know at least 2 efforts to do this by now. One at Facebook with Nuclide, and I believe VS Live Share does something similar.

I think it's an idea whose time has come, so I think it's pretty cool that so many people are doing it.

I'm happy with whatever works, but what I have in mind is very simple so I don't expect it to take a lot of engineering time :)

Reply on news.ycombinator.com