[cfe-dev] ClangD

[Val Markovic via cfe-dev]

>From the YCM side: I think this is a *fantastic* idea! We were thinking
about pulling out the C++ completion out of ycmd and into a separate server
that ycmd would talk to (much like it works for several other languages
already) but hearing that clang devs are taking this on saves us a bunch of
work!

And it's great to hear it will follow the common completion API MS is
pushing; we'll be supporting that API on the back-end of ycmd some time in
the future (and clangd might accelerate that). We're looking into possibly
supporting it on the front-end as well.

On Wed, Jan 25, 2017 at 6:38 AM, Manuel Klimek <klimek at google.com> wrote:

> On Wed, Jan 25, 2017 at 3:34 PM Jusufadis Bakamovic <jbakam at gmail.com>
> wrote:
>
>> Hi,
>>
>> I think this is an excellent idea which should be pursued as far as
>> possible as it will enable us to seamlessly integrate multiple clang-based
>> services into the development environment. Possibly it will enable us to
>> integrate non-clang-based kind of services as well. I might say that I've
>> developed a (prototype) solution which somewhat resembles this idea
>> (implementation goes up to extent of my current needs & time resources).
>> See [1] for a short overview but in general it is a generic, message-queue
>> based, client-server architecture which acts as a thin proxy layer between
>> the client requests and concrete service implementation (i.e.
>> syntax-highlighting, clang-format, etc.). Server transparently makes sure
>> that each service is run in its own context (thread/process) and provides
>> full-control of services (startup-(all), shutdown-(all), run, etc.): see
>> [2] for server implementation. This way a service developer can completely
>> put focus on service implementation details itself without caring about
>> other details. See [3] for base service implementation and [4] & [5] for
>> examples of concrete service implementations (clang-format service &
>> syntax-highlight service).
>>
>> What would be a way to get involved with ClangD?
>>
>
> Lurk on the cfe-commits mailing list for clangd based code reviews to come
> in (Benjamin is working on getting an initial prototype up), and contribute
> there.
>
> Once we have more of the basic infrastructure in place, we'll accept
> patches like we do for the rest of clang and have a bug list.
>
>
>>
>> Cheers,
>> Adi
>>
>> [1] https://github.com/JBakamovic/yavide/blob/master/
>> docs/services_framework.md#framework
>> [2] https://github.com/JBakamovic/yavide/blob/master/
>> core/server/yavide_server.py
>> [3] https://github.com/JBakamovic/yavide/blob/master/
>> core/services/yavide_service.py
>> [4] https://github.com/JBakamovic/yavide/blob/master/
>> core/services/clang_formatter_service.py
>> [5] https://github.com/JBakamovic/yavide/blob/master/
>> core/services/syntax_highlighter_service.py
>>
>>
>> On 25 January 2017 at 14:11, Manuel Klimek via cfe-dev <
>> 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
>> 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/20170125/a01170f9/attachment.html>