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

[Sam McCall via clangd-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20191125/2d862b80/attachment.html>