arphaman added a comment. In https://reviews.llvm.org/D49523#1169728, @malaperle wrote:
> In https://reviews.llvm.org/D49523#1169000, @arphaman wrote: > > > In https://reviews.llvm.org/D49523#1167553, @malaperle wrote: > > > > > Interesting! We also have a need for passing compilation commands in a > > > context where there is no compile_commands.json, but we were thinking of > > > putting this in a "didChangeConfiguration" message so that all the > > > commands would be available even before files are opened. This would be > > > allow Clangd to have the necessary information for background indexing > > > which would include unopened files. Subsequent changes to compilation > > > commands would probably go through a similar didChangeConfiguration and > > > the appropriate (opened) files would get reparsed (not unlike > > > https://reviews.llvm.org/D49267). I'm making a few guesses here: I assume > > > that in the context of XCode, you would not do background indexing in > > > Clangd but let XCode do it as it can also coordinate (and not overlap) > > > with build tasks. Is that correct? In any case, I think the approach in > > > the patch is not incompatible with what we had in mind, i.e. we could > > > also reuse "overrideCompilationCommandForFile" for each file specified in > > > didChangeConfiguration. I'm point this out because if you *do* end up > > > needing all the compilation commands beforehand like I mentioned, then > > > maybe we can skip the approach of specifying them with didOpen and send > > > them all with didChangeConfiguration from start. > > > > > > Thanks for your response, > > As it stands right now we will not run the indexer in Clangd for our use > > case, and it's unclear if we can even assemble a set of compile commands, > > so we would like to provide the commands when a file is open. We might be > > interested in a "didChangeConfiguration" message extension in the future > > (ideally it would be possible to change the subset of the constructed > > compilation database). > > > Sounds good, I think sending it in didOpen makes sense then. And yes, I agree > that we would need to support changing a subset of commands through > didChangeConfiguration, eventually! > > In https://reviews.llvm.org/D49523#1169620, @jkorous wrote: > > > Hi Marc-Andre, what is a structure of data you are passing as parameter of > > didChangeConfiguration message? > > > We don't yet :) But we will need to send the information per-file through it > instead of using the compile_commands.json. Right now, what is supported in > the didChangeConfiguration is pointing to a different compile_commands.json, > in order to support multiple configuration (actually pointing to the folder > containing the json file). > > > All we need is to pass per-file compilation command to clangd. Maybe we > > could send didChangeConfiguration message right after didOpen. > > > > EDIT: Well, provided we would find a way how not to parse the file twice. > > The idea would be to send the per-file commands to clangd *before* anything > is opened. So the didOpen would just read the latest command in memory. And > subsequent changes to commands would be communicated with > didChangeConfiguration and then files would get reparsed. I'm actually > thinking we might want to send the commands in the "initialize" request for > all the initial commands and then update them with didChangeConfiguration > whenever they change. That way, there is no risk for reparsing as we should > not do anything (indexing!) before the initialize. > But it doesn't sounds like you need this right now :) I reconsidered our needs. We would actually want to use the 'didChangeConfiguration' extension right now as well. I will work on a patch for it that is based on top of this one :) Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D49523 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
