[cfe-dev] ClangD

[Nikolai Kosjar via cfe-dev]

On 01/25/2017 03:13 PM, Manuel Klimek via cfe-dev wrote:
> On Wed, Jan 25, 2017 at 3:08 PM Alex L <arphaman at gmail.com
> <mailto:arphaman at gmail.com>> wrote:
>
>     Thanks Manuel, I'm quite excited to hear that about ClangD!
>
>     I have a couple of questions:
>     Do you think ClangD would be able to replace libclang in the future?
>     Would it be possible to deprecate libclang for IDE use after ClangD
>     catches up to it, or should we keep libclang as it is even after
>     that point?
>
>
> In the foreseeable future, I don't see libclang going away. Not
> everybody is able to switch to a new development workflow easily, and
> there is a lot of investment in the current libclang based workflows.

Just for clarity, please elaborate on "lot of investment in the current 
libclang based workflows".

>     On 25 January 2017 at 13:11, Manuel Klimek via cfe-dev
>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>         Hi fellow clang devs,
>
>         we wanted to let you know that we're (finally) starting up work
>         on ClangD, which you might know from email threads such as [1]
>         (June 2012!).
>
>         In the meantime, YCM had done a good enough job at packaging up
>         a libclang interface to our favorite editors, and other
>         priorities (like modules) have eaten up a lot of folks priority
>         lunches.
>
>         What has changed?
>         1. YCM is starting to develop more and more into a language
>         multiplexer, with other languages (Go, Typescript, etc)
>         providing their own servers to talk to
>         2. MS has created a language server protocol [2], which already
>         has both a bunch of client and server implementations
>         3. Debugging through python into libclang crashers is a pain and
>         eating our support resources
>         4. While libclang is a good abstraction if you want to have
>         something run in your process with close coupling, a standard
>         protocol like the language server protocol seems like a better
>         way to allow fast iterations on the server implementation
>         without the need to keep backward-compatibility hacks through a
>         restrictive C API.
>
>         One of the cool things about the MS language server protocol is
>         that it seems to not actually do any networking, which means
>         that we do not need to introduce any new dependencies into
>         clang-tools-extra, which is where we want to start developing this.
>
>         If you have any thoughts / concerns let me know; otherwise look
>         forward to code reviews on initial ClangD dropping by :D
>
>         Cheers,
>         /Manuel
>
>         [1] http://lists.llvm.org/pipermail/cfe-dev/2012-June/022028.html
>         [2] https://github.com/Microsoft/language-server-protocol
>
>
>         _______________________________________________
>         cfe-dev mailing list
>         cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>         http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>