ilya-biryukov added a comment. 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? Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D49758 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
