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

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Doug Schaefer
> Sent: Saturday, August 12, 2017 12:39 PM
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-dev] Thoughts on LSP / Clangd integration
> 
> 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.

And, yes, clang does C too. C++ is just the issue at hand.

With clangd's permissive license, it shouldn't be too big a deal to include the binaries in CDT.

> >
> >
> > 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
> _______________________________________________
> 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