You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
254 lines
11 KiB
254 lines
11 KiB
==========================
|
|
Clang's refactoring engine
|
|
==========================
|
|
|
|
This document describes the design of Clang's refactoring engine and provides
|
|
a couple of examples that show how various primitives in the refactoring API
|
|
can be used to implement different refactoring actions. The :doc:`LibTooling`
|
|
library provides several other APIs that are used when developing a
|
|
refactoring action.
|
|
|
|
Refactoring engine can be used to implement local refactorings that are
|
|
initiated using a selection in an editor or an IDE. You can combine
|
|
:doc:`AST matchers<LibASTMatchers>` and the refactoring engine to implement
|
|
refactorings that don't lend themselves well to source selection and/or have to
|
|
query ASTs for some particular nodes.
|
|
|
|
We assume basic knowledge about the Clang AST. See the :doc:`Introduction
|
|
to the Clang AST <IntroductionToTheClangAST>` if you want to learn more
|
|
about how the AST is structured.
|
|
|
|
.. FIXME: create new refactoring action tutorial and link to the tutorial
|
|
|
|
Introduction
|
|
------------
|
|
|
|
Clang's refactoring engine defines a set refactoring actions that implement
|
|
a number of different source transformations. The ``clang-refactor``
|
|
command-line tool can be used to perform these refactorings. Certain
|
|
refactorings are also available in other clients like text editors and IDEs.
|
|
|
|
A refactoring action is a class that defines a list of related refactoring
|
|
operations (rules). These rules are grouped under a common umbrella - a single
|
|
``clang-refactor`` command. In addition to rules, the refactoring action
|
|
provides the action's command name and description to ``clang-refactor``.
|
|
Each action must implement the ``RefactoringAction`` interface. Here's an
|
|
outline of a ``local-rename`` action:
|
|
|
|
.. code-block:: c++
|
|
|
|
class LocalRename final : public RefactoringAction {
|
|
public:
|
|
StringRef getCommand() const override { return "local-rename"; }
|
|
|
|
StringRef getDescription() const override {
|
|
return "Finds and renames symbols in code with no indexer support";
|
|
}
|
|
|
|
RefactoringActionRules createActionRules() const override {
|
|
...
|
|
}
|
|
};
|
|
|
|
Refactoring Action Rules
|
|
------------------------
|
|
|
|
An individual refactoring action is responsible for creating the set of
|
|
grouped refactoring action rules that represent one refactoring operation.
|
|
Although the rules in one action may have a number of different implementations,
|
|
they should strive to produce a similar result. It should be easy for users to
|
|
identify which refactoring action produced the result regardless of which
|
|
refactoring action rule was used.
|
|
|
|
The distinction between actions and rules enables the creation of actions
|
|
that define a set of different rules that produce similar results. For example,
|
|
the "add missing switch cases" refactoring operation typically adds missing
|
|
cases to one switch at a time. However, it could be useful to have a
|
|
refactoring that works on all switches that operate on a particular enum, as
|
|
one could then automatically update all of them after adding a new enum
|
|
constant. To achieve that, we can create two different rules that will use one
|
|
``clang-refactor`` subcommand. The first rule will describe a local operation
|
|
that's initiated when the user selects a single switch. The second rule will
|
|
describe a global operation that works across translation units and is initiated
|
|
when the user provides the name of the enum to clang-refactor (or the user could
|
|
select the enum declaration instead). The clang-refactor tool will then analyze
|
|
the selection and other options passed to the refactoring action, and will pick
|
|
the most appropriate rule for the given selection and other options.
|
|
|
|
Rule Types
|
|
^^^^^^^^^^
|
|
|
|
Clang's refactoring engine supports several different refactoring rules:
|
|
|
|
- ``SourceChangeRefactoringRule`` produces source replacements that are applied
|
|
to the source files. Subclasses that choose to implement this rule have to
|
|
implement the ``createSourceReplacements`` member function. This type of
|
|
rule is typically used to implement local refactorings that transform the
|
|
source in one translation unit only.
|
|
|
|
- ``FindSymbolOccurrencesRefactoringRule`` produces a "partial" refactoring
|
|
result: a set of occurrences that refer to a particular symbol. This type
|
|
of rule is typically used to implement an interactive renaming action that
|
|
allows users to specify which occurrences should be renamed during the
|
|
refactoring. Subclasses that choose to implement this rule have to implement
|
|
the ``findSymbolOccurrences`` member function.
|
|
|
|
The following set of quick checks might help if you are unsure about the type
|
|
of rule you should use:
|
|
|
|
#. If you would like to transform the source in one translation unit and if
|
|
you don't need any cross-TU information, then the
|
|
``SourceChangeRefactoringRule`` should work for you.
|
|
|
|
#. If you would like to implement a rename-like operation with potential
|
|
interactive components, then ``FindSymbolOccurrencesRefactoringRule`` might
|
|
work for you.
|
|
|
|
How to Create a Rule
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Once you determine which type of rule is suitable for your needs you can
|
|
implement the refactoring by subclassing the rule and implementing its
|
|
interface. The subclass should have a constructor that takes the inputs that
|
|
are needed to perform the refactoring. For example, if you want to implement a
|
|
rule that simply deletes a selection, you should create a subclass of
|
|
``SourceChangeRefactoringRule`` with a constructor that accepts the selection
|
|
range:
|
|
|
|
.. code-block:: c++
|
|
|
|
class DeleteSelectedRange final : public SourceChangeRefactoringRule {
|
|
public:
|
|
DeleteSelection(SourceRange Selection) : Selection(Selection) {}
|
|
|
|
Expected<AtomicChanges>
|
|
createSourceReplacements(RefactoringRuleContext &Context) override {
|
|
AtomicChange Replacement(Context.getSources(), Selection.getBegin());
|
|
Replacement.replace(Context.getSource,
|
|
CharSourceRange::getCharRange(Selection), "");
|
|
return { Replacement };
|
|
}
|
|
private:
|
|
SourceRange Selection;
|
|
};
|
|
|
|
The rule's subclass can then be added to the list of refactoring action's
|
|
rules for a particular action using the ``createRefactoringActionRule``
|
|
function. For example, the class that's shown above can be added to the
|
|
list of action rules using the following code:
|
|
|
|
.. code-block:: c++
|
|
|
|
RefactoringActionRules Rules;
|
|
Rules.push_back(
|
|
createRefactoringActionRule<DeleteSelectedRange>(
|
|
SourceRangeSelectionRequirement())
|
|
);
|
|
|
|
The ``createRefactoringActionRule`` function takes in a list of refactoring
|
|
action rule requirement values. These values describe the initiation
|
|
requirements that have to be satisfied by the refactoring engine before the
|
|
provided action rule can be constructed and invoked. The next section
|
|
describes how these requirements are evaluated and lists all the possible
|
|
requirements that can be used to construct a refactoring action rule.
|
|
|
|
Refactoring Action Rule Requirements
|
|
------------------------------------
|
|
|
|
A refactoring action rule requirement is a value whose type derives from the
|
|
``RefactoringActionRuleRequirement`` class. The type must define an
|
|
``evaluate`` member function that returns a value of type ``Expected<...>``.
|
|
When a requirement value is used as an argument to
|
|
``createRefactoringActionRule``, that value is evaluated during the initiation
|
|
of the action rule. The evaluated result is then passed to the rule's
|
|
constructor unless the evaluation produced an error. For example, the
|
|
``DeleteSelectedRange`` sample rule that's defined in the previous section
|
|
will be evaluated using the following steps:
|
|
|
|
#. ``SourceRangeSelectionRequirement``'s ``evaluate`` member function will be
|
|
called first. It will return an ``Expected<SourceRange>``.
|
|
|
|
#. If the return value is an error the initiation will fail and the error
|
|
will be reported to the client. Note that the client may not report the
|
|
error to the user.
|
|
|
|
#. Otherwise the source range return value will be used to construct the
|
|
``DeleteSelectedRange`` rule. The rule will then be invoked as the initiation
|
|
succeeded (all requirements were evaluated successfully).
|
|
|
|
The same series of steps applies to any refactoring rule. Firstly, the engine
|
|
will evaluate all of the requirements. Then it will check if these requirements
|
|
are satisfied (they should not produce an error). Then it will construct the
|
|
rule and invoke it.
|
|
|
|
The separation of requirements, their evaluation and the invocation of the
|
|
refactoring action rule allows the refactoring clients to:
|
|
|
|
- Disable refactoring action rules whose requirements are not supported.
|
|
|
|
- Gather the set of options and define a command-line / visual interface
|
|
that allows users to input these options without ever invoking the
|
|
action.
|
|
|
|
Selection Requirements
|
|
^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
The refactoring rule requirements that require some form of source selection
|
|
are listed below:
|
|
|
|
- ``SourceRangeSelectionRequirement`` evaluates to a source range when the
|
|
action is invoked with some sort of selection. This requirement should be
|
|
satisfied when a refactoring is initiated in an editor, even when the user
|
|
has not selected anything (the range will contain the cursor's location in
|
|
that case).
|
|
|
|
.. FIXME: Future selection requirements
|
|
|
|
.. FIXME: Maybe mention custom selection requirements?
|
|
|
|
Other Requirements
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
There are several other requirements types that can be used when creating
|
|
a refactoring rule:
|
|
|
|
- The ``RefactoringOptionsRequirement`` requirement is an abstract class that
|
|
should be subclassed by requirements working with options. The more
|
|
concrete ``OptionRequirement`` requirement is a simple implementation of the
|
|
aforementioned class that returns the value of the specified option when
|
|
it's evaluated. The next section talks more about refactoring options and
|
|
how they can be used when creating a rule.
|
|
|
|
Refactoring Options
|
|
-------------------
|
|
|
|
Refactoring options are values that affect a refactoring operation and are
|
|
specified either using command-line options or another client-specific
|
|
mechanism. Options should be created using a class that derives either from
|
|
the ``OptionalRequiredOption`` or ``RequiredRefactoringOption``. The following
|
|
example shows how one can created a required string option that corresponds to
|
|
the ``-new-name`` command-line option in clang-refactor:
|
|
|
|
.. code-block:: c++
|
|
|
|
class NewNameOption : public RequiredRefactoringOption<std::string> {
|
|
public:
|
|
StringRef getName() const override { return "new-name"; }
|
|
StringRef getDescription() const override {
|
|
return "The new name to change the symbol to";
|
|
}
|
|
};
|
|
|
|
The option that's shown in the example above can then be used to create
|
|
a requirement for a refactoring rule using a requirement like
|
|
``OptionRequirement``:
|
|
|
|
.. code-block:: c++
|
|
|
|
createRefactoringActionRule<RenameOccurrences>(
|
|
...,
|
|
OptionRequirement<NewNameOption>())
|
|
);
|
|
|
|
.. FIXME: Editor Bindings section
|