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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
