[cfe-dev] ClangD

[Manuel Klimek via cfe-dev]

On Thu, Jan 26, 2017 at 3:33 PM Nikolai Kosjar <nikolai.kosjar at qt.io> wrote:

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

YCM exists, and people use it. Xcode exists and people use it. There is a
python integration based on libclang. Probably more users :)


>
> >     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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170126/0a9e1095/attachment.html>