[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.


================
Comment at: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:39
+  /// Handles the source replacements that are produced by a refactoring action.
+  virtual void handle(AtomicChanges SourceReplacements) = 0;
+};
----------------
ioeric wrote:
> arphaman wrote:
> > ioeric wrote:
> > > I think this interface is specific to some refactoring rules and should be pushed down to derived classes.
> > Are you talking about derived classes of `RefactoringResultConsumer`? So something like
> > 
> > ```
> > class RefactoringResultConsumer {
> >   virtual void handleInvocationError(llvm::Error Err) = 0;
> > };
> > 
> > class RefactoringResultSourceReplacementConsumer: RefactoringResultConsumer {
> >  virtual void handle(AtomicChanges SourceReplacements) = 0;
> > };
> > ```
> > 
> > If yes, can you please clarify how the rule can call `handle` if it's in a subclass of `RefactoringResultConsumer`?
> > 
> Sorry, I thought the `handle` interface was dispatched by template. 
> 
> Maybe we can have default implementation of rule-specific handlers, e.g. generate errors, in the base class? Derived classes can implement handlers that they care about and ignore others.
Sure, I will add default implementations for `handle(...)`. 

I'm not sure about `handle...Error(Error)` though because `llvm::Error` forces some form of handling, and I don't want to use a generic stub that will silence the `llvm::Error` as it won't be that useful. The errors will be handled differently by different clients anyway, like clang-refactor might output the error to stderr, and clangd might either try to notify the user or silently swallow the error.


Repository:
  rL LLVM

https://reviews.llvm.org/D37291