<div dir="ltr">Hi Ken,<div><br></div><div>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.</div><div>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.<br></div><div>Sending didOpen and didChange request should also be a very simple change in the LSP client code.</div><div><br></div><div>Even though you don't control the client code, I suggest requesting this change from maintainers of the aforementioned clients.<br></div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 25, 2019 at 10:22 AM Sam McCall 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"><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" target="_blank">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>
_______________________________________________<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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div>