<div dir="ltr">Hi Ken,<div><br><div>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. </div><div>The C++ AST is often very large and expensive to build, though incremental rebuilds are usually cheap (preamble optimisation).</div><div>This means:</div><div> - in practice, requests on non-opened files may be extremely expensive (e.g. 20 seconds CPU-bound)</div><div> - we'd need to work out when the AST gets disposed for non-open files (for open files, this happens on didClose)</div><div><br></div><div>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?</div><div><br></div><div>An alternative would be to build a somewhat ad-hoc solution like using a pseudo-parser to give approximate outlines for non-opened files.</div><div><br></div><div>> balk because from a purist point of view, Clangd only gets the file contents from the client</div><div>That's not a concern - clangd needs to read from disk e.g. to understand the contents of #includes.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 25, 2019 at 9:56 AM Ken Domino via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Folks,<br>
<br>
I'm currently writing a bunch of extensions for Visual Studio 2019 to <br>
exercise the client-side functionality against different LSP servers. <br>
The VS2019 client code makes a textDocument/documentSymbol request just <br>
after initialization, which is perfectly fine according to the LSP spec. <br>
However, in Clangd, if it hadn't received the textDocument/didOpen <br>
request first, it returns an error because the file is untracked in <br>
DraftMgr--which is an equally fine interpretation of the spec. So, the <br>
VS2019 client never works with Clangd. I have a patch to Clangd to fix <br>
this, reading the file from the file system and then adding the doc so <br>
it is tracked. But the question is whether people are going to balk <br>
because from a purist point of view, Clangd only gets the file contents <br>
from the client. I have no control over the client because it's MS code, <br>
and I'd rather not write a client from scratch at this point--I'd rather <br>
spend time working on my server for Antlr and other programming <br>
languages. What do people think about having Clangd read from disk for <br>
any untracked docs?<br>
<br>
Note, I'm sending this to the old mail list instead of Discourse or <br>
Discord or whatever people call it--not many are using it, the UI isn't <br>
easy, and not as simple as sending an email.<br>
<br>
Ken Domino<br>
<br>
_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div>