Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Thoughts on LSP / Clangd integration

>From my (especially Windows based) user point of view, I have just the
following to add:

I looked now for a long time on clang and it took a long time, until
they even provided windows builds. A windows user is usually not
expecting to compile the tools from source by themself, they expect

The second thing, that the user expects from a toolchain (compiler) is,
that it is working, and that the full way. The problem with clang is,
that they place themelf as a *compiler* replacement, but not providing
the full toolchain, which would require to have also the libs and
runtimes. For this, you would need to install on windows either a gcc or
even a MS Windows SDK / compiler, in order to actually create an

So, if I have to install either of MS or gcc compiler, why would I now
install the clang? I don't see the benefit of it, since gcc now also
provides much better failre reporting. I can't give any input on
compiling performance, since I'm not doing C++ development, but only C.

>From your request, I also only see "our C++ editor" .. I guess, C++
gives you a lot of headache, but there is and will still be C (here we
have now C11). The question is, if you go that direction, will the
tooling still be able to cope with the languages for those, that don't
used clang at all. As said above, clang is not providing the full
toolchain to create a full binary. In that case, if you base your whole
CDT tooling on that LSP4E / clangd, then you have to include it somehow
into CDT, with the option for users to use their own, if they already
have it locally.

Am 30.07.2017 um 23:46 schrieb Nathan Ridge:
> 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]
> [2]
> [3]
> [4]
> [5]
> [6]
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top