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

Eric Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Aug 31 05:51:58 PDT 2017


ioeric 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;
+};
----------------
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.


Repository:
  rL LLVM

https://reviews.llvm.org/D37291





More information about the cfe-commits mailing list