<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 26, 2017 at 3:33 PM Nikolai Kosjar <<a href="mailto:nikolai.kosjar@qt.io">nikolai.kosjar@qt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/25/2017 02:11 PM, Manuel Klimek via cfe-dev wrote:<br class="gmail_msg">
> Hi fellow clang devs,<br class="gmail_msg">
><br class="gmail_msg">
> we wanted to let you know that we're (finally) starting up work on<br class="gmail_msg">
> ClangD, which you might know from email threads such as [1] (June 2012!).<br class="gmail_msg">
><br class="gmail_msg">
> In the meantime, YCM had done a good enough job at packaging up a<br class="gmail_msg">
> libclang interface to our favorite editors, and other priorities (like<br class="gmail_msg">
> modules) have eaten up a lot of folks priority lunches.<br class="gmail_msg">
><br class="gmail_msg">
> What has changed?<br class="gmail_msg">
> 1. YCM is starting to develop more and more into a language multiplexer,<br class="gmail_msg">
> with other languages (Go, Typescript, etc) providing their own servers<br class="gmail_msg">
> to talk to<br class="gmail_msg">
> 2. MS has created a language server protocol [2], which already has both<br class="gmail_msg">
> a bunch of client and server implementations<br class="gmail_msg">
> 3. Debugging through python into libclang crashers is a pain and eating<br class="gmail_msg">
> our support resources<br class="gmail_msg">
> 4. While libclang is a good abstraction if you want to have something<br class="gmail_msg">
> run in your process with close coupling, a standard protocol like the<br class="gmail_msg">
> language server protocol seems like a better way to allow fast<br class="gmail_msg">
> iterations on the server implementation without the need to keep<br class="gmail_msg">
> backward-compatibility hacks through a restrictive C API.<br class="gmail_msg">
><br class="gmail_msg">
> One of the cool things about the MS language server protocol is that it<br class="gmail_msg">
> seems to not actually do any networking, which means that we do not need<br class="gmail_msg">
> to introduce any new dependencies into clang-tools-extra, which is where<br class="gmail_msg">
> we want to start developing this.<br class="gmail_msg">
><br class="gmail_msg">
> If you have any thoughts / concerns let me know; otherwise look forward<br class="gmail_msg">
> to code reviews on initial ClangD dropping by :D<br class="gmail_msg">
<br class="gmail_msg">
[Huch, my first association with "ClangD" was support for the D language]<br class="gmail_msg">
<br class="gmail_msg">
Hi!<br class="gmail_msg">
<br class="gmail_msg">
We from the Qt Creator IDE team are also interested in this. :)<br class="gmail_msg">
<br class="gmail_msg">
Some notes:<br class="gmail_msg">
<br class="gmail_msg">
1. You've indirectly referenced the initial design document at [1]. Will<br class="gmail_msg">
this get an update or is it already updated somewhere else? An updated<br class="gmail_msg">
document clarifying the scope and goals would be probably useful to all<br class="gmail_msg">
interested parties, also in regard to contribution and how to align own<br class="gmail_msg">
current development that uses libclang/libtooling/clang tools.<br class="gmail_msg"></blockquote><div><br></div><div>So far the scope is replacing the C++ parts of YCM (that is, code completion, code browsing, "fast" syntax checking and fixits)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
E.g. Qt Creator also already launches a separate process<br class="gmail_msg">
("clangbackend") that makes use of libclang to provide the basic<br class="gmail_msg">
functionality like updated diagnostics, highlighting information and<br class="gmail_msg">
results for completion requests.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
2. How is clangd related to "clang-refactor" [2]?<br class="gmail_msg">
<br class="gmail_msg">
If it's not related at all, what's the state of clang-refactor?<br class="gmail_msg"></blockquote><div><br></div><div>clang-refactor is still in the design stage. I think at some point we'll probably want to integrate clang-refactor, but we first want a prototype and see how well that goes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
3. I take this opportunity to share our biggest problems with libclang<br class="gmail_msg">
from the Qt Creator perspective since clangd users will probably face<br class="gmail_msg">
them also (as far as I understand, clangd will be based upon libclang -<br class="gmail_msg">
please correct me if I'm wrong). I share this in hope that they will be<br class="gmail_msg">
addressed or taken into consideration during the development of clangd<br class="gmail_msg">
for the benefit of all interested parties now that the development of<br class="gmail_msg">
clangd is announced. Please keep in mind that the actual problems might<br class="gmail_msg">
be in other components that libclang makes use of.<br class="gmail_msg">
<br class="gmail_msg">
The problems we are facing with libclang, in this order, are:<br class="gmail_msg">
<br class="gmail_msg">
3.1 Windows-specific issues<br class="gmail_msg">
<br class="gmail_msg">
The whole performance of parse/reparse in general is worser than on<br class="gmail_msg">
Mac/Linux (probably also because of slow IO on Windows). At the end of<br class="gmail_msg">
the day, this makes it less usable on Windows for real-world<br class="gmail_msg">
projects/files. There are also other Windows-specific issues.<br class="gmail_msg">
<br class="gmail_msg">
My gut feeling is that there aren't that many libclang users on Windows.<br class="gmail_msg">
<br class="gmail_msg">
@Manual: To which extend do you or your team use and develop on Windows?<br class="gmail_msg"></blockquote><div><br></div><div>We are not Windows developers :) We hope that by integrating with VS Code / MS language protocol we can get some interested parties on Windows, but so far we rely on help from Windows wizards.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are any Windows developers working on clangd?<br class="gmail_msg"></blockquote><div><br></div><div>Well, it'll be an open source project ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Concrete issues are:<br class="gmail_msg">
<br class="gmail_msg">
  * Preamble is also generated for the second reparse on Windows<br class="gmail_msg">
    <a href="https://llvm.org/bugs/show_bug.cgi?id=28535" rel="noreferrer" class="gmail_msg" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=28535</a><br class="gmail_msg">
<br class="gmail_msg">
  * Problems with FileManager caches leading to leaking file descriptors<br class="gmail_msg">
    <a href="https://reviews.llvm.org/D27810" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D27810</a><br class="gmail_msg">
<br class="gmail_msg">
  * Very slow reparsing for big header and even slower with<br class="gmail_msg">
    preamble-generation enabled (might be related to the one above)<br class="gmail_msg">
    <a href="https://llvm.org/bugs/show_bug.cgi?id=31353" rel="noreferrer" class="gmail_msg" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=31353</a><br class="gmail_msg">
<br class="gmail_msg">
  * Windows: Crash with absolute path with forward slashes<br class="gmail_msg">
    <a href="https://llvm.org/bugs/show_bug.cgi?id=28381" rel="noreferrer" class="gmail_msg" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=28381</a><br class="gmail_msg">
<br class="gmail_msg">
3.2 Synchronous/blocking API<br class="gmail_msg">
Low-latency completion results at all times are impossible with a single<br class="gmail_msg">
CXTranslationUnit that is just being parsed or reparsed. This gets worse<br class="gmail_msg">
the longer the parse/reparse takes (hello Windows).<br class="gmail_msg">
<br class="gmail_msg">
One can mitigate this by triggering the parse/reparse after a<br class="gmail_msg">
significant timeout of user-typing-inactivity, but this leads to a<br class="gmail_msg">
sluggish experience regarding new diagnostics and highlighting<br class="gmail_msg">
informations (you don't want to wait more than 2s for new diagnostics to<br class="gmail_msg">
see if your code is valid now).<br class="gmail_msg">
<br class="gmail_msg">
Another approach is to use two CXTranslationUnits per file, so at least<br class="gmail_msg">
there is always a non-blocking CXTranslationUnits ready for completion<br class="gmail_msg">
requests. Downside is doubled memory consumption and potentially<br class="gmail_msg">
threading issues (@Manual: do they still exist or are they already<br class="gmail_msg">
resolved?).<br class="gmail_msg"></blockquote><div><br></div><div>I work on a very large codebase and don't have problems with code completion. I think all YCM integrations I know take care to not block the UI for completion requests (or in general).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.3 libclang requires unsaved files to exist on disk.<br class="gmail_msg">
<br class="gmail_msg">
If the unsaved file does not exist a preamble generation will happen for<br class="gmail_msg">
every reparse which simply takes to long.<br class="gmail_msg"></blockquote><div><br></div><div>I would be surprised if that was true - I often work on unsaved files without seeing these problems.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
For the concrete use case, refer to<br class="gmail_msg">
<br class="gmail_msg">
        <a href="https://llvm.org/bugs/show_bug.cgi?id=31112" rel="noreferrer" class="gmail_msg" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=31112</a><br class="gmail_msg">
<br class="gmail_msg">
This one might be also a problem if you do version control checkouts and<br class="gmail_msg">
files suddenly vanish.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Best regards,<br class="gmail_msg">
    Nikolai<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
[1] <a href="https://github.com/chandlerc/llvm-designs/blob/master/ClangService.rst" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/chandlerc/llvm-designs/blob/master/ClangService.rst</a><br class="gmail_msg">
[2] <a href="http://lists.llvm.org/pipermail/cfe-dev/2016-September/050641.html" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2016-September/050641.html</a><br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Cheers,<br class="gmail_msg">
> /Manuel<br class="gmail_msg">
><br class="gmail_msg">
> [1] <a href="http://lists.llvm.org/pipermail/cfe-dev/2012-June/022028.html" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2012-June/022028.html</a><br class="gmail_msg">
> [2] <a href="https://github.com/Microsoft/language-server-protocol" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/Microsoft/language-server-protocol</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> cfe-dev mailing list<br class="gmail_msg">
> <a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="gmail_msg">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>