This enables more execution modes like standalone and Mapreduce-style execution.
See also D41729
Paths
| Differential D41730
[clangd] Use ToolExecutor to write the global-symbol-builder tool. ClosedPublic Authored by ioeric on Jan 4 2018, 9:35 AM.
Details Summary This enables more execution modes like standalone and Mapreduce-style execution. See also D41729
Diff Detail
Event TimelineHerald added subscribers: cfe-commits, ilya-biryukov, klimek. · View Herald TranscriptJan 4 2018, 9:35 AM Comment Actions The implementation looks good, but to see whether sam has high-level comments on this.
ioeric marked 2 inline comments as done. Comment ActionsAddress review comments.
Comment Actions This makes SymbolCollector (production code) depend on YAML (explicitly experimental), as well as on Tooling interfaces. 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? Comment Actions Address review comment: move all ToolExecutor and YAML-specific logics out of SymbolCollector. Comment Actions
Thanks for the catch! I completely missed these perspectives...
WrapperFrontendAction is helpful here. All changes have been moved into the tool now. PTAL This revision is now accepted and ready to land.Jan 9 2018, 4:58 AM Closed by commit rL322084: [clangd] Use ToolExecutor to write the global-symbol-builder tool. (authored by ioeric). · Explain WhyJan 9 2018, 7:23 AM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 128723 clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp
clangd/index/SymbolCollector.h
clangd/index/SymbolCollector.cpp
clangd/index/SymbolYAML.h
clangd/index/SymbolYAML.cpp
unittests/clangd/SymbolCollectorTests.cpp
|
might be also mention The YAML result is safe to concatenate.