ilya-biryukov added a reviewer: ilya-biryukov.
ilya-biryukov added a comment.
Comment at: clangd/ClangdLSPServer.cpp:430
CDB.clear();
-
-reparseOpenedFiles();
+compileCommandsChangePost(CCChangeData);
}
ilya-biryukov wrote:
> simark wrote:
> >
ilya-biryukov added a comment.
> if/when we have a native implementation, supporting multiple mechanisms with
> different layering requirements to get at most a 2x win in watcher resource
> usage seems like a dubious way to spend our complexity budget.
I guess the only think that might force
sammccall added a comment.
Just a couple of high-level comments here:
- I'm not sure we can/should commit to supporting editor-based file watching
forever.
- One natural long-term direction would be to get this functionality into
`JSONCompilationDatabase`, and clients of that don't have an
simark added inline comments.
Comment at: clangd/ClangdLSPServer.cpp:430
CDB.clear();
-
-reparseOpenedFiles();
+compileCommandsChangePost(CCChangeData);
}
malaperle wrote:
> ilya-biryukov wrote:
> > Maybe keep the old logic of reparsing all open
malaperle added inline comments.
Comment at: clangd/ClangdLSPServer.cpp:430
CDB.clear();
-
-reparseOpenedFiles();
+compileCommandsChangePost(CCChangeData);
}
ilya-biryukov wrote:
> Maybe keep the old logic of reparsing all open files? This would
ilya-biryukov added a comment.
In https://reviews.llvm.org/D49267#1173291, @simark wrote:
> Ok, I agree that having clangd watch files itself could be necessary at some
> point (when the client does not support it), but it would have to be
> configurable. In our case, we have efficient enough
simark added a comment.
In https://reviews.llvm.org/D49267#1173266, @ilya-biryukov wrote:
> The approach is not ideal, but may be a good middle ground before we figure
> out how we approach file watching in clangd. Note that there are other things
> that won't force the updates currently, e.g.
ilya-biryukov added a comment.
In https://reviews.llvm.org/D49267#1171932, @simark wrote:
> I guess you mean language client here, not language server. In our case we
> already have a client capable of file watching, so it's convenient for us to
> do that (plus, this is what the LSP
simark added a comment.
In https://reviews.llvm.org/D49267#1171286, @ilya-biryukov wrote:
> Thanks for putting up this change! It can be really annoying that clangd does
> not pick up the compile commands that got updated.
>
> A few things of the top of my head on why we might want to punt on
ilya-biryukov added a subscriber: sammccall.
ilya-biryukov added a comment.
@sammccall pointed out that I've been looking at a different layer of caching.
Clangd does per-directory (to avoid reloading compilation database multiple
times) and per-file (to avoid calling into compilation database
ilya-biryukov added a comment.
Herald added a subscriber: arphaman.
Thanks for putting up this change! It can be really annoying that clangd does
not pick up the compile commands that got updated.
A few things of the top of my head on why we might want to punt on using the
LSP watches:
- File
simark updated this revision to Diff 155284.
simark added a comment.
Remove unintended changes
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D49267
Files:
clangd/ClangdLSPServer.cpp
clangd/ClangdLSPServer.h
clangd/GlobalCompilationDatabase.cpp
simark added a comment.
Note, https://reviews.llvm.org/D49265 in clang is a prerequisite.
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D49267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
simark created this revision.
Herald added subscribers: cfe-commits, jkorous, MaskRay, ioeric, ilya-biryukov.
This patch adds support for watching for changes to
compile_commands.json, and reparsing files if needed.
The watching is done using the "workspace/didChangeWatchedFiles"
notification,
14 matches
Mail list logo
