[PATCH] D49758: [clangd] allow clients to pass in compilationDatabaseChanges in the 'workspace/didChangeConfiguration' request

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

In https://reviews.llvm.org/D49758#1178056, @ilya-biryukov wrote:

> In https://reviews.llvm.org/D49758#1177747, @arphaman wrote:
>
> > In https://reviews.llvm.org/D49758#1174629, @ilya-biryukov wrote:
> >
> > > The mode of operation where compile commands come from the client seems useful, but I wonder if there's any value in mixing it with `compile_commands.json` and other CDB plugins.
> > >  Do you plan to use the overridden commands in conjunction with CDB plugins or do you want the client to exclusively control the compile commands?
> >
> >
> > The client will control the commands exclusively.
>
>
> Maybe a cleaner design would be to untangle the two use-cases and control them with a flag to clangd?
>  I.e. we can have two implementations of compilation databases in clangd:
>
> - one that uses clang tooling capabilities, i.e. reads compile_commands.json, etc.
> - one that gets all compile commands from the protocol and won't use the clang tooling. The command-line arg to clangd will control which implementation is used.
>
>   The advantage is that we don't have to think about interactions between the clang plugins and explicit overrides and it should be easier to make sure that we don't accidentally read compilation args from the wrong place. Would also help to keep DirectoryBasedCompilationDatabase a bit simpler, and the other implementation would be extremely simple. WDYT?


Sounds good to me. I'll update the patch to do that.
I'll add the flag as well. We won't be setting this flag directly though, our XPC protocol will assume it, but that's fine for us.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49758