[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:30
+  /// the source selection has no overlap at all with any relevant AST nodes.
+  virtual void handleInitiationFailure() = 0;
+
----------------
klimek wrote:
> ioeric wrote:
> > Just wondering if it is possible to provide more information about the initiation failure to the handler?
> Also, why is initiationFailure not simply handled via handleError?
Initiation failure is not really an error as such. It corresponds to a selection in an editor that doesn't overlap with any interesting AST at all. In the editor, the rule will fail to be initiated without a concrete error when we request it, or will be skipped when the editor is querying available actions for some selection. Therefore it doesn't really have any other information.

However, your comments made me reconsider this particular design point. We should emit an error for this kind of initiation failure as well, and `clang-refactor` will benefit by default as it will consume it and display it. The editor clients will be able to avoid this kind of error if they want by inspecting the selection constraint prior to invocation.

I will remove this method and use just `handleError` when committing.


https://reviews.llvm.org/D37291