kadircet added a comment. In D96245#2602293 <https://reviews.llvm.org/D96245#2602293>, @sammccall wrote:
> Will the fixes/actions this enables really be available synchronously? The fixes stay as is today, but the action might be just a command that needs to be invoked by the client (so it is still synchronous, in a sense, but instead of an edit embedder just initiates another action on the clangdserver, which will synchronously do "something") > AFAIK the only reasons we attach fixes to diagnostics are: > > - because clang fixes are generated at parse time and need to be stored > somewhere > - for the benefit of embedders that need the fix content synchronously with > the diagnostic > - to trigger the "fix available" text > > The first two points don't apply if the fix content is too slow to compute > synchronously. (And the third can be more simply solved with a boolean flag > instead) > The alternative is just to discover these fixes through the code action flow > (and allow modules to contribute code actions, which we should do anyway) Agreed, I was going this way because currently there was no way to provide a code action to clangd::diagnostic apart from storing it in the fixes map while generating it. I suppose it is more sensible to just go with a new hook on modules that can provide a codeaction given a clangd::diagnostic. (and when the diagnostic is seen, the module can just set a boolean flag or increment some fix counter as you suggested). Does `std::vector<CodeAction> contributeActions(const CodeActionParams&);` look like a good signature for the module hook? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96245/new/ https://reviews.llvm.org/D96245 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
