This revision updates `RewriteRule` to support multiple subrules that are
interpreted as an ordered-choice (apply the first one that matches). With this
feature, users can write the rules that appear later in the list of subrules
knowing that previous rules' patterns *have not matched*, freeing them from
reasoning about those cases in the current pattern.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61335
llvm-svn: 361037
Summary:
Changes the signature of the TextGenerator std::function to return an Expected<std::string>
instead of std::string to allow for (non-fatal) failures. Previously, we
expected that any failures would be expressed with assertions. However, that's
unfriendly to running the code in servers or other places that don't want their
library calls to crash the program.
Correspondingly, updates Transformer's handling of failures in TextGenerators
and the signature of `ChangeConsumer`.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61015
llvm-svn: 359574
Summary: This fixes a few places in the Stencil implementation where a unique_ptr is created at a callsite that expects shared_ptr. Since the former implicitly converts to the latter, the code compiles and runs correctly as is. But, there's no reason to involve unique_ptr -- the current code was leftover from a previous version in which unique_ptr was the expected type.
Reviewers: sbenza
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61005
llvm-svn: 359468
On configurations with -Werror,-Wmissing-field-initializers, the commit does not compile. This commit fixes the offending line.
Original Differential Revision: https://reviews.llvm.org/D60408
llvm-svn: 358705
Summary: This revision allows users to specify independent changes to multiple (related) sections of the input. Previously, only a single section of input could be selected for replacement.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60408
llvm-svn: 358697
Summary:
This file defines the *Stencil* abstraction: a code-generating object, parameterized by named references to (bound) AST nodes. Given a match result, a stencil can be evaluated to a string of source code.
A stencil is similar in spirit to a format string: it is composed of a series of raw text strings, references to nodes (the parameters) and helper code-generation operations.
See thread on cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling" for background.
Reviewers: sbenza
Reviewed By: sbenza
Subscribers: ilya-biryukov, mgorny, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59371
llvm-svn: 358691
Summary:
For example, a renamed type in a header file can conflict with declaration in
a random file that includes the header, but we should not consider the decl ambiguous if
it's not visible at the rename location. This improves consistency of generated replacements
when header file is included in different TUs.
Reviewers: hokein
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60257
llvm-svn: 358378
Summary: Adds a basic version of Transformer, a library supporting the concise specification of clang-based source-to-source transformations. A full discussion of the end goal can be found on the cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling".
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ioeric, ABataev, mgorny, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59376
llvm-svn: 357768
Summary:
Introduces a utility library in Refactoring/ to collect routines related to
source-code manipulation. In this change, we move "extended-range" functions
from the FixIt library (in clangTooling) to this new library.
We need to use this functionality in Refactoring/ and cannot access it if it
resides in Tooling/, because that would cause clangToolingRefactor to depend on
clangTooling, which would be a circular dependency.
Reviewers: ilya-biryukov, ioeric
Reviewed By: ilya-biryukov
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60269
llvm-svn: 357764
Summary: Adds a basic version of Transformer, a library supporting the concise specification of clang-based source-to-source transformations. A full discussion of the end goal can be found on the cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling".
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59376
llvm-svn: 357576
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Looks like these were in place to make these types move-only. That's
generally not a feature that the type should prescribe (unless it's an
inherent limitation) - instead leaving it up to the users of a type.
llvm-svn: 349669
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
Summary:
The OccurrencesFinder is only used in RenameOccurrences to find symbol
occurrences, there is no need to inherit RefactoringRule.
Replace it with a single utility function to avoid code misleading.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D39796
llvm-svn: 317696
when needed
This commit implements the semicolon insertion logic into the extract
refactoring. The following rules are used:
- extracting expression: add terminating ';' to the extracted function.
- extracting statements that don't require terminating ';' (e.g. switch): add
terminating ';' to the callee.
- extracting statements with ';': move (if possible) the original ';' from the
callee and add terminating ';'.
- otherwise, add ';' to both places.
Differential Revision: https://reviews.llvm.org/D39441
llvm-svn: 317343
This commit changes the way that the refactoring operation classes are
structured:
- Users have to call `initiate` instead of constructing an instance of the
class. The `initiate` is now supposed to have custom initiation logic, and
you don't need to subclass the builtin requirements.
- A new `describe` function returns a structure with the id, title and the
description of the refactoring operation.
The refactoring action classes are now placed into one common place in
RefactoringActions.cpp instead of being separate.
Differential Revision: https://reviews.llvm.org/D38985
llvm-svn: 316780
This commit adds an initial, skeleton outline of the "extract function"
refactoring. The extracted function doesn't capture variables / rewrite code
yet, it just basically does a simple copy-paste.
The following initiation rules are specified:
- extraction can only be done for executable code in a function/method/block.
This means that you can't extract a global variable initialize into a function
right now.
- simple literals and references are not extractable.
This commit also adds support for full source ranges to clang-refactor's test
mode.
Differential Revision: https://reviews.llvm.org/D38982
llvm-svn: 316465
consecutive statements
This commit adds a CodeRangeASTSelection value to the refactoring library. This
value represents a set of selected statements in one body of code.
Differential Revision: https://reviews.llvm.org/D38835
llvm-svn: 316104
Summary:
* Support rename alias.
* Add unittests for renaming alias.
* Don't generate fixes for the SourceLocations that are invalid or in temporary
buffer, otherwise crash would be happened when generating AtomicChanges.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D39043
llvm-svn: 316074
This commit allows the refactoring library to use its own set of
refactoring-specific diagnostics to reports things like initiation errors.
Differential Revision: https://reviews.llvm.org/D38772
llvm-svn: 315924
Summary:
Also contain a fix:
* Fix a false positive of renaming a using shadow function declaration.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D38882
llvm-svn: 315898
The recommit fixes a UB bug that occurred only on a small number of bots.
Original message:
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315661
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315087
This commit simplifies the interface for the refactoring action rules and the
refactoring requirements. It merges the selection constraints and the selection
requirements into one class. The refactoring actions rules must now be
implemented using subclassing instead of raw function / lambda pointers. This
change also removes a bunch of template-based traits and other
template definitions that are now redundant.
Differential Revision: https://reviews.llvm.org/D37681
llvm-svn: 314704
local-rename action
This commit introduces the clang-refactor tool alongside the local-rename action
which uses the existing renaming engine used by clang-rename. The tool
doesn't actually perform the source transformations yet, it just provides
testing support. This commit also moves only one test from clang-rename over to
test/Refactor. I will continue to move the other tests throughout
development of clang-refactor.
The following options are supported by clang-refactor:
-v: use verbose output
-selection: The source range that corresponds to the portion of the source
that's selected (currently only special command test:<file> is supported).
Please note that a follow-up commit will migrate clang-refactor to
libTooling's common option parser, so clang-refactor will be able to use
the common interface with compilation database and options like -p, -extra-arg,
etc.
The testing support provided by clang-refactor is described below:
When -selection=test:<file> is given, clang-refactor will parse the selection
commands from that file. The selection commands are grouped and the specified
refactoring action invoked by the tool. Each command in a group is expected to
produce an identical result. The precise syntax for the selection commands is
described in a comment in TestSupport.h.
Differential Revision: https://reviews.llvm.org/D36574
llvm-svn: 313244
Summary:
The use case is that renaming multiple symbols in a large enough codebase is
much faster if all of these can be done with a single invocation, but
there will be multiple translation units where one or more symbols are
not found.
Old behavior was to exit with an error (default) or exit without
reporting an error (-force). New behavior is that -force results in a
best-effort rename: rename symbols which are found and just ignore the
rest.
The existing help for -force sort of already implies this behavior.
Reviewers: cfe-commits, klimek, arphaman
Reviewed By: klimek
Differential Revision: https://reviews.llvm.org/D37634
llvm-svn: 312942
form of PseudoObjectExpr
The new commit adjusts unittest test code compilation options so that the
Objective-C code in the unittest can be parsed on non-macOS platforms.
Original message:
The AST selection finder now constructs a selection tree that contains only the
syntactic form of PseudoObjectExpr. This form of selection tree is more
meaningful when doing downstream analysis as we're interested in the syntactic
features of the AST and the correct lexical parent relation.
llvm-svn: 312132
of PseudoObjectExpr
The AST selection finder now constructs a selection tree that contains only the
syntactic form of PseudoObjectExpr. This form of selection tree is more
meaningful when doing downstream analysis as we're interested in the syntactic
features of the AST and the correct lexical parent relation.
llvm-svn: 312127
This patch implements the initial support for refactoring action rules. The
first rule that's supported is a "source change" rule that returns a set of
atomic changes. This patch is based on the ideas presented in my RFC:
http://lists.llvm.org/pipermail/cfe-dev/2017-July/054831.html
The following pieces from the RFC are added by this patch:
- `createRefactoringRule` (known as `apply` in the RFC)
- `requiredSelection` refactoring action rule requirement.
- `selection::SourceSelectionRange` selection constraint.
Differential Revision: https://reviews.llvm.org/D36075
llvm-svn: 311884
This commit adds the base AST source selection component to the refactoring
library. AST selection is represented using a tree of SelectedASTNode values.
Each selected node gets its own selection kind, which can actually be None even
in the middle of tree (e.g. statement in a macro whose child is in a macro
argument). The initial version constructs a "raw" selection tree, without
applying filters and canonicalisation operations to the nodes.
Differential Revision: https://reviews.llvm.org/D35012
llvm-svn: 311655
Symbol occurrences store the results of local rename and will also be used for
the global, indexed rename results. Their kind is used to determine whether they
should be renamed automatically or not. They can be converted to a set of
AtomicChanges as well.
Differential Revision: https://reviews.llvm.org/D36156
llvm-svn: 310853
a declaration at location and for class that searches for all occurrences of
a specific declaration
This commit uses a single RecursiveSymbolVisitor class for both
USRLocFindingASTVisitor and NamedDeclOccurrenceFindingVisitor to avoid duplicate
traversal code. It also traverses nested name specifier locs in the new class
and remove the separate matching step.
Differential Revision: https://reviews.llvm.org/D34949
llvm-svn: 307898
This is a short-term fix for PR33650 aimed to get the modules build bots green again.
Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.
Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)
Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.
Differential Revision: https://reviews.llvm.org/D34907
Corresponding LLVM change is r306878.
llvm-svn: 306881
Summary: ... which applies a set of `AtomicChange`s on code.
Reviewers: klimek, djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30777
llvm-svn: 298913
Summary:
An AtomicChange is used to create and group a set of source edits, e.g.
replacements or header insertions. Edits in an AtomicChange should be related,
e.g. replacements for the same type reference and the corresponding header
insertion/deletion.
An AtomicChange is uniquely identified by a key position and will either be
fully applied or not applied at all. The key position should be the location
of the key syntactical element that is being changed, e.g. the call to a
refactored method.
Next step: add a tool that applies AtomicChange.
Reviewers: klimek, djasper
Reviewed By: klimek
Subscribers: alexshap, cfe-commits, djasper, mgorny
Differential Revision: https://reviews.llvm.org/D27054
llvm-svn: 296616
Yitzhak Mandelbaum