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

[Ken Domino via clangd-dev]

I've made an implementation for implicit file opens (client asks for 
language features, but doen't actually do the open request). Please 
check out 
https://llvm.discourse.group/t/clangd-explicit-and-implicit-doc-open/205

--Ken


On 11/25/2019 4:22 AM, Sam McCall 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 <mailto: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 <mailto:clangd-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>