Disabled by default and hidden, caching for most implementation
already happens outside clangd, so we rarely need to change it.
Details
- Reviewers
sammccall
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 19224 Build 19224: arc lint + arc unit
Event Timeline
Testing should be possible with lit tests, I'll look into that. Let me know if there's anything else about this patch that needs attention. Thanks!
Generally LG.
I guess you might be able to test this by starting with a/compile_flags.txt and a/b/x.cc, and then adding a/b/compile_flags.txt?
clangd/ClangdLSPServer.h | ||
---|---|---|
38 | (the options split looks a little odd from the outside. One could make an argument for inheriting ClangdLSPServer::Options from ClangdServer::Options and adding the compile-commands/code completion options there. No need to restructure anything in this patch though) | |
105 | nit: any reason for unique_ptr over optional? | |
clangd/tool/ClangdMain.cpp | ||
141 | init(true) to avoid changing behavior? |
clangd/ClangdLSPServer.h | ||
---|---|---|
38 | Options struct SG, even though is number of params is manageable, and we have just a single call of this ctor at the time. | |
105 | CachingCompilationDb is non-movable (because of std::mutex field), so we can't properly initialize it in ctor-initializers. | |
clangd/tool/ClangdMain.cpp | ||
141 | This is intentional, it seems false is a better default, given that all implementation in LLVM cache it all themselves. |
clangd/tool/ClangdMain.cpp | ||
---|---|---|
141 | I agree the default should be false, at least eventually. I'm not sure what you're suggesting though - we change the default value of the flag in our own copy when we link against our DB that doesn't cache? That could work. I wonder if this will break others who might have similar DBs. |
clangd/tool/ClangdMain.cpp | ||
---|---|---|
141 | I suggested telling our users to set this flag to true. The flag is of no use if we're the only ones who need to set it to 'true', but 'true' is also the default.
Do we know of anyone else who builds clangd with custom DB implementations? |
Does this change affect the switching of compilation database, through workspace/didChangeConfiguration ?
A recent change (D49267) is another indication that caching might be doing more wrong than good. I assume the caching does not give us much performance-wise, we only request compile commands for file reparses and reparses tend to be slow and do lots of file system accesses anyway.
Maybe we should just disable it altogether. @sammccall, @simark, WDYT?
Yeah, the caching is bad and we should get rid of it. I thought an option would make this smoother but I no longer think so.
AFAIK the only people who actually need this option at present are internal google users due to our suspicious CDB.
Those people aren't well-served by having to set an option. Let's find another solution for that and then just remove the caching?
(the options split looks a little odd from the outside. One could make an argument for inheriting ClangdLSPServer::Options from ClangdServer::Options and adding the compile-commands/code completion options there. No need to restructure anything in this patch though)