Discussion on a simpler C++ user experience

[niosus]

Hey guys.

I will start with a small disclaimer. I completely understand the logic behind this:

Specifically, LSP avoids building functionality that does not exist in Sublime Text, or that serves only one language.

Nevertheless, I wanted to have a very open and open-ended conversation about the possible steps to improve the vanilla C++ pipeline. Also, feel free to point me where you would think such a discussion could take place if you feel like this is not a place for it. I looked into the #lsp chat in Discord, but I wanted some more permanent discussion.

For a couple of years now I've been developing EasyClangComplete (some of the contributors here have also been contributing over the years there, thanks!) and while I'm quite happy with the results it keeps feeling too specific for C++ with lots of hacky solutions all over the place and the LSP sounds like a more universal way to go. So I wanted to have a discussion on what you guys think would be possible to do in order to address a number of language-specific things that make or break user experience. I am talking about:

• compile_commands.json file generation. Currently, the proper backend would be clangd which requires a generated compilation database. The issue is that generating the compilation database is a tedious manual step, that I've done my best to take off the user's hands in ECC. I believe this is really a number one issue that scares off new users.
• headers are hard. It seems that clangd will spit out garbage when encountering headers as they would be canonically missing from the compilation database. I see a couple of ways to mitigate this:
  • CMake/Bazel/whatever files could be updated so that the headers are actually injected into the compilation database. This worked pretty well for me in multiple real projects big and small.
  • In a lot of cases header files are paired with some source file and can therefore use the same compilation flags. I've been using this approach in ECC and it doesn't really have too many shortcomings. The question is how to feed this to clangd, especially in a sustainable manner.
• if the compilation database is generated for a specific compiler, which is not clang, we might run into problems with specific non-standard instructions used by the compilers, e.g. gcc. Don't know if it is a problem of the completion plugin, but it is a problem nevertheless.
• there are probably other things I am missing now, but that is a start.

tldr: While I'm happy developing and using my own plugin, I feel this is a bit of a wasted effort as LSP seems to provide most of the functionality (show info, rename under cursor etc.) that is general and ideally should be used for any language. I'd say the main contribution of ECC now is the glue between libclang and the user. So I was wondering if you guys think there is a place for me to contribute smth like that here, i.e., some glue between clangd through LSP and the user. I am open to any suggestions.

[rchl]

Specifically, LSP avoids building functionality that does not exist in Sublime Text, or that serves only one language.

Nevertheless, I wanted to have a very open and open-ended conversation about the possible steps to improve the vanilla C++ pipeline.

While LSP avoids that, the LSP-* packages are a perfect fit for adding language-specific functionality, as far as I can tell. There doesn't seem to be a clang specific LSP-* package now but it should be no problem to create one.

There might be limits to how much of LSP (core package) you can hook into from the LSP-* package but if you are talking about having more typical sublime plugin functionality as an extra then it should be fine, I think. Not sure what others think.

BTW. I've loved your project back in the days when I was coding in C++, but I don't do that anymore so naturally, I've lost interest in it. But it's an impressive achievement on many fronts. :)

[niosus]

@rchl I was wondering why you stopped contributing 😉
Glad to hear that it wasn't something that I've done ☺️

Thanks for the reply. That sounds interesting. I will have a look into creating a clang-based LSP package. Let's see how much of ECC I can squeeze in there with how much efforts.

[rwols]

Thanks for showing interest and reaching out @niosus!
Auto-generation of compile_commands.json would be nice. But, it would entail maintaining build systems like:

• CMake
• Bazel
• Plain makefiles (?)
• Scons (?)
• Visual Studio solution files (?)

It sounds like a significant effort!

CMake/Bazel/whatever files could be updated so that the headers are actually injected into the compilation database. This worked pretty well for me in multiple real projects big and small.

clangd already uses heuristics to match a header file with the corresponding cpp file for suitable compile commands. The docs are a bit out of date in that regard.

if the compilation database is generated for a specific compiler, which is not clang, we might run into problems with specific non-standard instructions used by the compilers, e.g. gcc. Don't know if it is a problem of the completion plugin, but it is a problem nevertheless.

The --query-driver command-line argument is supposed to solve the cross-compilation problem: https://clangd.llvm.org/troubleshooting.html

Like @rchl mentioned langserver-specific stuff goes in an LSP-clangd package.

Consider implementing the textDocument/typeHierarchy request. It is for now non-standard, so we cannot implement it in this base package. Altought it might become standard: microsoft/vscode-languageserver-node#426. This unused functionality has been available in clangd for a while.

If you like, we can host a potential LSP-clangd package in the sublimelsp org making you the maintainer (if that's okay with @rchl, @predragnikolic, @tomv564).

[niosus]

Thanks for such a full reply @rwols!

Auto-generation of compile_commands.json would be nice. But, it would entail maintaining build systems

This is something that I already take care of in ECC. CMake seems to be working well. I have just added a script to generate a compilation database from Bazel following https://github.com/grailbio/bazel-compilation-database and all the others are left for manual generation. Surprisingly, I've had really few issues with that over the last 2 or so years.

clangd already uses heuristics to match a header file with the corresponding cpp file

That is great to hear! I will have to research a bit on that as I am not really familiar with what exactly happens under the hood in clangd.

Also, thanks for the suggestions on where to start. I will have a look into the textDocument/typeHierarchy request.

I think the best way would be for me to start having a look into this and then once I have a minimal proof of concept, I would be happy to move it into the LSP space if you guys think it makes sense. My main issue is that this would still be a hobby project, and I still don't want to let ECC die until there is a viable replacement + I start a new job from April on, which will eat into my free time significantly.

[ofirgall]

Have you heard about bear? https://github.com/rizsotto/Bear

[predragnikolic]

Will close this discussion, because it is a bit stale.

As noted,
all of the requirements can be achieved with a LSP-clangd plugin.

The only thing left is to create a plugin like that.
That didn't happen yet, but it doesn't mean that it wont. :)

[predragnikolic]

@niosus if you ever want to continue this topic in the future,
or have any questions, feel free to ask here or at discord https://discord.gg/TZ5WN8t

[niosus]

Thanks guys. As these things go, the time has become even more limited for me recently, so I probably won't undertake this. Also, because I need to mostly work through ssh nowadays, I actually had to switch to VSCode so I only have time to somewhat maintain the plugin I wrote before, but I don't have the time for a significant refactoring of the functionality that would need to be stripped out of it to fit in into what we discuss here. I am totally fine if somebody else ever sees the value and decides to build up on this discussion and would be happy to chat with them about it.

Thanks for your time guys nevertheless. 🙏

[predragnikolic]

LSP-clangd is now published on Package Control thanks to @LDAP 🙂
https://packagecontrol.io/packages/LSP-clangd