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. changes to the included headers > won't cause rebuilds of the source files until user modifies them. And those > are much more frequent than changes to compile_commands.json, so they seem > like a more pressing problem. 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 file watching in the client, and already watch the files in the workspace. Since the inotify watches are limited per-user, having clangd watch them too means we'll have duplicates, and therefore waste a rather limited resource. Actually, clangd could simply use the client capabilities. If the client advertises support for file watching with dynamic registration, use that, otherwise use the internal mechanism. In the mean time, I don't think the current patch paints us in a corner. The logic of checking whether the effective compile commands for open files changes would stay even if the file watching mechanism changes. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D49267 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
