This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Add an option controlling caching of compile commands.
AbandonedPublic

Authored by ilya-biryukov on Jun 12 2018, 3:37 AM.

Details

Reviewers
sammccall
Summary

Disabled by default and hidden, caching for most implementation
already happens outside clangd, so we rarely need to change it.

Event Timeline

ilya-biryukov created this revision.Jun 12 2018, 3:37 AM

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?
(With optional, I think it's clear enough to remove the comment)

clangd/tool/ClangdMain.cpp
141

init(true) to avoid changing behavior?

ilya-biryukov added inline comments.Jun 13 2018, 1:57 AM
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.
I'm not a big fan of inheriting data structs, though, would rather use composition.

105

CachingCompilationDb is non-movable (because of std::mutex field), so we can't properly initialize it in ctor-initializers.
And we need it to pass it into ClangdServer in ctor-initializers, so it's hard to put the init code into the ctor body.
That all looks brittle, but I wouldn't refactor this in this patch.

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.
We should set to true for our CDB that actually needs it. WDYT?

sammccall added inline comments.Jun 13 2018, 2:10 AM
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.

ilya-biryukov added inline comments.Jun 13 2018, 2:50 AM
clangd/tool/ClangdMain.cpp
141

I suggested telling our users to set this flag to true.
Otherwise I think we should just punt on this change and not introduce the flag. If we'll have dependency tracking, caching could probably be nicely incorporated into the build system integration and than we'll just remove the caching from ClangdLSPServer.
Happy to go this way, BTW, I don't think this cache creates any problems apart from some inefficiency.

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.

I wonder if this will break others who might have similar DBs.

Do we know of anyone else who builds clangd with custom DB implementations?
If there are any and this change breaks them, we can revert it.

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?

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?

ilya-biryukov abandoned this revision.Nov 26 2018, 7:25 AM