[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

Eric Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Apr 12 08:10:39 PDT 2019


ioeric added inline comments.


================
Comment at: clangd/TUScheduler.cpp:338
+      Barrier(Barrier), Done(false) {
+  FileInputs.CompileCommand = CDB.getFallbackCommand(FileName);
+}
----------------
ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > The command is filled with a fallback by `ClangdServer`, right? Why do we need to repeat this here?
> > `ASTWorker::FileInputs` is not set until ASTWorker runs update and gets compile command. Before that, `FileInputs` contains empty compile command that can be used by `runWithPreamble`/`runWithAST` (afaict). Initializing it to fallback command seems to be a better alternative.
> That makes sense. Could we remove the `getFallbackCommand` call from the `ClangdServer::addDocument`?
> Let's make the `TUScheduler` fully responsible for the compile command.
Sounds good. 


================
Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand &ASTWorker::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}
----------------
ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > This is racy, `FileInputs` is only accessed from a worker thread now.
> > > I'm afraid we'll need a separate variable with a lock around it (could reuse one lock for preamble and compile command, probably)
> > It looks like we could also guard `FileInputs`? Adding another variable seems to make the state more complicated. 
> `FileInputs` are currently accessed without locks in a bunch of places and it'd be nice to keep it that way (the alternative is more complicated code).
> Doing the same thing we do for preamble looks like the best alternative here.
The reason I think it would be easier to guard `FileInputs` with mutex instead of pulling a new variable is that CompileCommand is usually used along with other fields in `FileInputs`.  I think we could manage this with relatively few changes. Please take a look at the new changes.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60607/new/

https://reviews.llvm.org/D60607





More information about the cfe-commits mailing list