[clangd-dev] textDocument/didOpen, file tracking, reading files from disk, etc.

[Ilya Biryukov via clangd-dev]

Hi Ken,

In addition to the resource management concerns, I would argue that not
requiring didOpen is a bug in the protocol and all the clients should do
this.
Filesystem accesses are prone to races and communicating the contents of
the open files through the protocol makes the interaction model between
editors and language servers much "clearer" from the theoretical
perspective.
Sending didOpen and didChange request should also be a very simple change
in the LSP client code.

Even though you don't control the client code, I suggest requesting this
change from maintainers of the aforementioned clients.

This also aligns with how VSCode does things, which seems to be the most
feature-complete and most widely used LSP client. Aligning with widely used
clients ensures more language servers work without extra modifications,
which should also be a good thing for any LSP client implementation.

On Mon, Nov 25, 2019 at 10:22 AM Sam McCall via clangd-dev <
clangd-dev at lists.llvm.org> wrote:

> Hi Ken,
>
> The main difficulty here is that clangd builds and holds a clang AST for
> each file that's open, and uses it to serve requests.
> The C++ AST is often very large and expensive to build, though incremental
> rebuilds are usually cheap (preamble optimisation).
> This means:
>  - in practice, requests on non-opened files may be extremely expensive
> (e.g. 20 seconds CPU-bound)
>  - we'd need to work out when the AST gets disposed for non-open files
> (for open files, this happens on didClose)
>
> Whether we can find appropriate choices here depends a bit on what the
> workflow is - what does it use the documentSymbol results for? Are the
> documents actually open?
>
> An alternative would be to build a somewhat ad-hoc solution like using a
> pseudo-parser to give approximate outlines for non-opened files.
>
> > balk because from a purist point of view, Clangd only gets the file
> contents from the client
> That's not a concern - clangd needs to read from disk e.g. to understand
> the contents of #includes.
>
> On Mon, Nov 25, 2019 at 9:56 AM Ken Domino via clangd-dev <
> clangd-dev at lists.llvm.org> wrote:
>
>> Folks,
>>
>> I'm currently writing a bunch of extensions for Visual Studio 2019 to
>> exercise the client-side functionality against different LSP servers.
>> The VS2019 client code makes a textDocument/documentSymbol request just
>> after initialization, which is perfectly fine according to the LSP spec.
>> However, in Clangd, if it hadn't received the textDocument/didOpen
>> request first, it returns an error because the file is untracked in
>> DraftMgr--which is an equally fine interpretation of the spec. So, the
>> VS2019 client never works with Clangd. I have a patch to Clangd to fix
>> this, reading the file from the file system and then adding the doc so
>> it is tracked. But the question is whether people are going to balk
>> because from a purist point of view, Clangd only gets the file contents
>> from the client. I have no control over the client because it's MS code,
>> and I'd rather not write a client from scratch at this point--I'd rather
>> spend time working on my server for Antlr and other programming
>> languages. What do people think about having Clangd read from disk for
>> any untracked docs?
>>
>> Note, I'm sending this to the old mail list instead of Discourse or
>> Discord or whatever people call it--not many are using it, the UI isn't
>> easy, and not as simple as sending an email.
>>
>> Ken Domino
>>
>> _______________________________________________
>> clangd-dev mailing list
>> clangd-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>>
> _______________________________________________
> clangd-dev mailing list
> clangd-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>


-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20191125/7d597dc7/attachment.html>