arphaman added a comment. You
In https://reviews.llvm.org/D38985#901152, @sammccall wrote: > Hi Alex! I'm working on clangd, but am pretty new to the project, so forgive > some naive questions. > > I'm a bit unclear at a high level what the new abstractions in this patch > add, in terms of wiring refactorings up to clangd and other tools. > My understanding is: we have a hierarchy of refactorings consisting of > actions (roughly: user intent?) and rules (roughly: implementations). > > Clangd needs to be able to: > > - enumerate the actions and their associated rules: possible via > `createRefactoringActions()` > - find names for these (machine readable and human readable): possible at the > `Action` level, not `Rule` yet > - determine whether rules can be applied and what configuration is needed: > possible via the `Rule` API > - invoke rules: possible via the `Rule` API Right. > So AFAICT, clangd could be hooked up to the existing Refactor API, without > `EditorCommand` or `EditorClient`. What's the gain? - EditorCommand is not a necessity, but an abstraction to keep the rule simple. I thought it'd be good to have them in a registry for some libclang uses (particularly mapping to C API enums), but on a second though I think that this can be avoided. I'll avoid the class altogether then. - EditorClient simplifies the editor operation and will be reused in libclang. Repository: rL LLVM https://reviews.llvm.org/D38985 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
