[PATCH] D38985: [refactor] Add support for editor commands that connect IDEs/editors to the refactoring actions

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

In https://reviews.llvm.org/D38985#906893, @sammccall wrote:

> Thanks, this looks a bunch simpler.
>
> I have a question about the direction here: AFAICS there's various efforts in the refactoring infrastructure to allow consumers of the Refactor libs (e.g. clang-refactor, clangd, XCode?) to operate without knowing the details of the refactorings.
>
> One example is the treating the identifying `Name` of a rule as data, instead of referring to a subclass directly. Another is the way options are communicated via `OptionsVisitor` and `Requirement`s etc, where they could be more directly expressed as members of a `Rule`-specific struct or parameters to a function.
>
> An interface that truly decouples N refactorings from M consumers has scalability advantages, but there are some things that cut against it:
>
> - It tends to add complexity/indirection, which can slow down contributors, mask bugs, and makes certain features (ones that don't fit into the existing framework) hard to add.
> - If the generic interfaces aren't enough we pierce them, resulting in both coupling *and* complexity. e.g. Clangd really needs control over how refactorings are exposed: which ones are visible under what names, how the JSON-RPC messages are structured. (Because its protocol isn't really an implementation detail under our control, we need to be able to adapt to/influence editors and evolution of the LSP standard).


Good point. I agree, it would be good to have a regular refactoring-specific interface that can be used by clangd and provide a more generic abstraction at another layer. However, I think that Clangd will still benefit from a generic editor interface because not all refactorings will have special protocol support in LSP.

I've updated the patch and tried an approach that's somewhat similar to the proposed one.
Please take a look!

> What's the biggest value we get out of the generic interface? Whose life would get harder if refactorings had this strawman interface/concept?
> 
>   template<typename Options, typename Result>
>   class Refactoring {
>      bool available(RefactoringContext&, const Options&) = 0;
>      Error invoke(RefactoringContext&, const Options&, RefactoringConsumer&) = 0;
>   }
>    
> 
> @klimek may have thoughts here.


Repository:
  rL LLVM

https://reviews.llvm.org/D38985