[cdt-dev] Thoughts on LSP / Clangd integration

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

Hi folks,

Doug has previously brought up [1] the topic of Clangd [2], a clang-based language server that implements the Language Server Protocol [3].

The prospect of using Clangd to power a C++ editor / IDE is exciting, because it means being able to reuse clang's parser and related functionality instead of having to roll our own.

As mentioned in Doug's post, there is an "LSP4E" project underway [4] that allows Eclipse to act as an LSP client, with the functionality integrated into the Generic Editor [5].

Finally, to connect the dots, Marc-André Laperle has written an "lsp4e-cpp" plugin [6], that allows LSP4E to connect to Clangd, and thereby get Clangd-powered C++ editor functionality in Eclipse.

All of these projects are currently in a fairly early stage of development. However, I'm thinking ahead about what will be a good way to get this functionality in front of users, and how - if at all - lsp4e-cpp should be integrated with CDT.

I can think of a few options:

  1) Not integrated with CDT.

      In this scenario, users wanting to take advantage of Clangd
      in Eclipse would install Clangd, LSP4E, and lsp4e-cpp (which
      would then need to have its own releases and its own update
      site), and would not need to install CDT.

  2) Integrated into CDT as a new project type.

      In this scenario, lsp4e-cpp could be part of CDT. A user
      would install Clangd, LSP4E, and CDT, and create a new
      kind of project, say "C/C++ LSP Project". Source files in 
      that project would open up with the Generic Editor, and
      use the LSP/Clangd functionality.

  3) Integrated into CDT, usable by existing projects

      In this scenario, users could choose to open files in
      their existing projects with either the current C++ editor,
      or the Generic Editor, which would then use the LSP/
      Clangd functionality. This has the advantage of allowing
      users to start benefiting from the functionality in their
      existing projects.

      I believe this is more or less what happens right now
      if you install Marc-André's plugin.

  4) Integrated into CDT's C++ editor

      In this scenario, rather than using LSP4E's integration
      with the Generic Editor, we could integrate the LSP-
      powered functionality into the current C++ editor itself.
      (For example, for code completion, we could have a new
      completion proposal computer that uses the LSP). We
      could probably still reuse large parts of LSP4E to achieve
      this.

      This option would involve the most work, but it would have
      the advantage of allowing users to transition to LSP
      without losing functionality. For example, currently LSP
      does not have semantic highlighting support, but our C++
      editor does. With this approach, users could continue to
      enjoy semantic highlighting in our C++ editor, while
      benefitting from other things (like code completion) powered
      by LSP in the same editor.

Does anyone have thoughts about which of these integration options would be a good choice? There may, of course, be other options I haven't considered as well.

Regards,
Nate

[1] https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg31710.html
[2] https://clang.llvm.org/extra/clangd.html
[3] https://github.com/Microsoft/language-server-protocol/
[4] https://projects.eclipse.org/projects/technology.lsp4e
[5] https://www.eclipse.org/eclipse/news/4.7/M3/#generic-editor
[6] https://git.eclipse.org/r/#/c/101857/