Thoughts on LSP / Clangd integration

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Thoughts on LSP / Clangd integration

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Marc-André Laperle

I think #3 is not too much effort, gives enough flexibility to the user and makes it easy to try out. It could be an optional feature in the normal CDT update site. I don't expect anyone to use this except for tinkering with Clangd unless someone spends (much more) time on #4.


Cheers,

Marc-André


From: [hidden email] <[hidden email]> on behalf of Nathan Ridge <[hidden email]>
Sent: Sunday, July 30, 2017 5:46:51 PM
To: CDT Mailing List
Cc: Marc-Andre Laperle
Subject: [cdt-dev] Thoughts on LSP / Clangd integration
 
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Nathan Ridge
> I don't expect anyone to use this except for tinkering with Clangd unless someone
> spends (much more) time on #4.

Not even once LSP4E and Clangd mature a bit and become more featureful?

Regards,
Nate
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Marc-André Laperle

Not even once LSP4E and Clangd mature a bit and become more featureful?


I meant, at this moment, there's probably too many missing things compared to CDT for someone to choose the generic editor over CDT's so I think it will be more useful for people interested in Clangd itself. But yeah, if both LSP4E and Clangd mature then I can definitely see situations where users would prefer the Generic editor + Clangd. You can already get very accurate diagnostics with the right setup so it's promising.


Marc-André


From: [hidden email] <[hidden email]> on behalf of Nathan Ridge <[hidden email]>
Sent: Sunday, July 30, 2017 8:16:47 PM
To: CDT Mailing List
Subject: Re: [cdt-dev] Thoughts on LSP / Clangd integration
 
> I don't expect anyone to use this except for tinkering with Clangd unless someone
> spends (much more) time on #4.

Not even once LSP4E and Clangd mature a bit and become more featureful?

Regards,
Nate
_______________________________________________
cdt-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Doug Schaefer-3

I’ve been working on a new editor for Momentics and was looking at our ASTRewriting and how we leverage the LTK refactoring engine to present a nice UI, bundles changes into a single undoable edit, etc. Along with Codan (which still has a lot of unfulfilled promise) and a super fast (relatively) indexer, the bar is set pretty high for something else to come along and replace our static analysis engine.

 

Assuming clangd will give us everything we need to replace our parsers and services that use them, it would be good to have a way to track it’s progress and start integrating it for real. Despite the thinking of certain people, CDT ain’t going anywhere for quite a while J, and this would help cement that.

 

Without looking too deeply yet, my gut tells me it may actually be less work to start a new editor. The CEditor is a million years old and is getting rusty. I’m not totally sold that the generic editor is easier, but that’s worth another look. I didn’t use it for my Momentics build file editor since I couldn’t see how it did document partitioning. There is some elegance to the Platform editor framework that shouldn’t be hidden. Once I finish my editor, I’ll take a look at this.

 

Doug.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Marc-André Laperle
Sent: Monday, July 31, 2017 12:26 AM
To: CDT Mailing List <[hidden email]>
Subject: Re: [cdt-dev] Thoughts on LSP / Clangd integration

 

> Not even once LSP4E and Clangd mature a bit and become more featureful?

 

I meant, at this moment, there's probably too many missing things compared to CDT for someone to choose the generic editor over CDT's so I think it will be more useful for people interested in Clangd itself. But yeah, if both LSP4E and Clangd mature then I can definitely see situations where users would prefer the Generic editor + Clangd. You can already get very accurate diagnostics with the right setup so it's promising.

 

Marc-André


From: [hidden email] <[hidden email]> on behalf of Nathan Ridge <[hidden email]>
Sent: Sunday, July 30, 2017 8:16:47 PM
To: CDT Mailing List
Subject: Re: [cdt-dev] Thoughts on LSP / Clangd integration

 

> I don't expect anyone to use this except for tinkering with Clangd unless someone
> spends (much more) time on #4.

Not even once LSP4E and Clangd mature a bit and become more featureful?

Regards,
Nate
_______________________________________________
cdt-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Nathan Ridge
Thanks for your thoughts Doug.

> my gut tells me it may actually be less work to start a new editor

Just to make sure I'm understanding correctly: do you mean a new editor to combine editor functions powered by LSP with editor functions powered by our existing parser, or a new editor for LSP functionality only?

Thanks,
Nate
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Doug Schaefer-3
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Nathan Ridge
> Sent: Thursday, August 3, 2017 1:06 AM
> To: CDT General developers list. <[hidden email]>
> Subject: Re: [cdt-dev] Thoughts on LSP / Clangd integration
>
> Thanks for your thoughts Doug.
>
> > my gut tells me it may actually be less work to start a new editor
>
> Just to make sure I'm understanding correctly: do you mean a new editor to
> combine editor functions powered by LSP with editor functions powered by
> our existing parser, or a new editor for LSP functionality only?

That's a good question. I guess it should do both and we have a toggle that selects which system to use.

I just fear that the toggle will spread through a lot of code. For example, I've been looking at the refactorings we have. They'll all have to be totally redone which would mean each of the actions will have to look at the toggle to know what to do. How many other things do we have like that? Starting with a fresh new editor is a plan not to have to deal with that and just add features as they're ready.

Open to suggestions.

>
> Thanks,
> Nate
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

kesselhaus
In reply to this post by Nathan Ridge
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
> [hidden email]
> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Doug Schaefer-3
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: [hidden email] [mailto:[hidden email]]
> On Behalf Of kesselhaus
> Sent: Saturday, August 12, 2017 8:16 AM
> To: [hidden email]
> 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Doug Schaefer-3
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Doug Schaefer
> Sent: Saturday, August 12, 2017 12:39 PM
> To: CDT General developers list. <[hidden email]>
> 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: [hidden email] [mailto:cdt-dev-
> [hidden email]]
> > On Behalf Of kesselhaus
> > Sent: Saturday, August 12, 2017 8:16 AM
> > To: [hidden email]
> > 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
> > > [hidden email]
> > > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Thoughts on LSP / Clangd integration

Nathan Ridge
In reply to this post by kesselhaus
> 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.

We will definitely not require users to compile clangd from source :)
I expect the clangd project will provide binaries in due course, and
we could even optionally ship them with CDT for convenience.

Keep in mind both projects (clangd, and our integration with it), are
at a very early stage. The current state of things does not reflect
the state things will be in when we have a shipping product.

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

As Doug already clarified, using clangd to power editor features does
not require using clang to produce your binaries. You can continue
producing your binaries with whatever compiler you want.

(The notion of using different compiler engines to build your code
and to analyze it might seem prone to incompatibilities, but in fact
Microsoft has been doing it all along: Visual Studio's IntelliSense
engine is powered by the proprietary EDG compiler front-end, which
is different from what MSVC uses for actual compilation.)

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

Sorry, I tend to focus in on C++ sometimes because that is what I
use CDT for :)

Clang (and clangd) support C just as well as C++. In fact, using
clangd will help fill gaps in our C support as well. For example,
there are some C11 features like "_Generic" that we don't currently
support. With clangd we'll get that support for free as well.

Regards,
Nate
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Loading...