Re: [cdt-dev] Thoughts on LSP / Clangd integration

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

Had a feeling this would happen. We're talking about clangd which is an executable built out of the clang/llvm source tree. It's a separate thing that IDE vendors that use it would redistribute. You don't need to install clang the compiler.

Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of kesselhaus
> Sent: Saturday, August 12, 2017 8:16 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: 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 binaries.
> 
> 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 executables.
> 
> 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] 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/
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev