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

[Ken Domino via clangd-dev]

Hi Sam,

Thanks for the reply. I wasn't sure whether the lists.llvm.org Mailing 
Lists was in use anymore.

There are several problems here. The first problem is the LSP spec 
itself. When I read the spec, what the open request really is is a lock, 
where "truth" is code-speak for a write lock. Making this substitution 
in mind, it starts to be a little clearer. I've been trying to raise 
awareness of the wording problem in the spec, as well as format issues 
(e.g., STEM articles usually use section numbers so one can identify 
concisely things that need to be changed), but who knows.

So, as implemented, Clangd currently requires a write lock from the 
client. Should Clangd require a write lock just to just use the language 
feature services like "go to def", "find all refs", "hover", etc? I just 
want to open a file, and maybe see what is the type of an auto, navigate 
around to understand how the code works before I start editing it. As 
you say, #include's are already read out-of-band, which are not locked 
explicitly by the client. So, I'd like to submit my change request for 
that, as soon as I can figure out how to refer to a file on disk under 
clangd/test.

The second issue is memory management. I would recommend a garbage 
collection scheme of the open files, configurable to the memory size or 
number of files in the cache. (I'm not sure what multiple opens and 
closes from the same client means, as the spec doesn't explain this at 
all. But no matter.) When the ref count is zero, Clangd can keep it 
around--because as you say, it can take 20 s to reload from scratch--or 
remove it if another file is opened and hits one of these limits. I can 
work on this later this week.

Ken