[PATCH] D41730: [clangd] Use ToolExecutor to write the global-symbol-builder tool.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

This makes `SymbolCollector` (production code) depend on YAML (explicitly experimental), as well as on Tooling interfaces.
At least we should invert this by making the thing passed to SymbolCollector a `function<void(const Symbol&)>` or so.

Moreover, it's unfortunate we'd need to change SymbolCollector at all. Currently it's a nice abstraction that does one thing (AST -> `SymbolSlab`), now we're making it do two things. It can't be for scalability reasons - there's no problem fitting all the symbols from a TU in memory. So why do we need to do this?
I don't really understand the `ToolExecutor` interfaces well, but ISTM overriding `SymbolIndexActionFactory::runInvocation` to flush the symbols in the slab out to the `ExecutionContext` would allow you to use `SymbolCollector` unchanged?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D41730