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:
This affects overloaded operators, which are represented by a
CXXOperatorCallExpr whose first child is always a DeclRefExpr referring to the
operator. For infix, postfix and call operators we want the first argument
to be traversed before the operator.
Reviewers: arphaman
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37200
llvm-svn: 312633
Summary:
We need to specialize this because RecursiveASTVisitor visits template
template parameters after the templated declaration, unlike the order in
which they appear in the source code.
Reviewers: arphaman
Reviewed By: arphaman
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36998
llvm-svn: 312631
rule classes
This commit changes the way that the refactoring results are produced. Instead
of using different `RefactoringActionRule` subclasses for each result type,
Clang now use a single `RefactoringResultConsumer`. This was suggested by
Manuel in https://reviews.llvm.org/D36075.
Differential Revision: https://reviews.llvm.org/D37291
llvm-svn: 312316
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
Module builds somehow report an ambiguity between clang::Diagnostic and
clang::Tooling::Diagnostic. It seems as if one of the additional headers
brought in by the module brings the clang namespace to the toplevel. I
could not find out the reason for that, so for now I go with the simple
fix to bring the build back to green.
rdar://33321397
llvm-svn: 308071
Summary:
To get properly integration Clang-Tidy with CLion IDE, next things were implemented:
1) Preserve `Message`, `FileOffset`, `FilePath` in the clang-tidy output.
2) Export all diagnostics, not just the ones with fixes
3) Test-cases
Reviewers: klimek, ilya-biryukov, alexfh
Reviewed By: alexfh
Subscribers: alexfh, JDevlieghere, mgorny, xazax.hun, cfe-commits, klimek
Tags: #clang-tools-extra
Patch by Vladimir Plyashkun!
Differential Revision: https://reviews.llvm.org/D34404
llvm-svn: 308014
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
arguments when `-fsyntax-only` is used
Previously, Clang failed to create a fixed compilation database when the
compilation arguments use -fsyntax-only instead of -c. This commit fixes the
issue by forcing Clang to look at the compilation job when stripping the
positional arguments.
Differential Revision: https://reviews.llvm.org/D34687
llvm-svn: 306659
... once each for the syntactic and semantic form. Without this fix, behavior
of the newly added tests would have been
InitListExprIsPreOrderVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderVisitedTwice:
syntactic: 0
semantic: 1
InitListExprIsPreOrderNoQueueVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderNoQueueVisitedTwice:
syntactic: 0
semantic: 2
llvm-svn: 306374
...instead of -std=c99, as the latter lead to
error: invalid argument '-std=c99' not allowed with 'C++'
complaints in test logs
Differential Revision: https://reviews.llvm.org/D34417
llvm-svn: 306373
No-one was using this, and it's not meaningful in general -- FrontendActions
can be run on inputs that don't have a corresponding source file. The current
frontend input can be obtained by asking the FrontendAction if any future
action actually needs it.
llvm-svn: 305045
Now FixedCompilationDatabase::loadFromCommandLine has no means to report
which error occurred if it fails to create compilation object. This is
a block for implementing D33013, because after that change driver will
refuse to create compilation if command line contains erroneous options.
This change adds additional argument to loadFromCommandLine, which is
assigned error message text if compilation object was not created. This is
the same way as other methods of CompilationDatabase report failure.
Differential Revision: https://reviews.llvm.org/D33272
llvm-svn: 303741
Summary: This is the first change as part of developing a clang-query based search and replace tool.
Reviewers: klimek, bkramer, ioeric, sbenza, jbangert
Reviewed By: ioeric, jbangert
Subscribers: sbenza, ioeric, cfe-commits
Patch by Julian Bangert!
Differential Revision: https://reviews.llvm.org/D29621
llvm-svn: 302624
The previous algorithm processed one character at a time, which is very
painful on a modern CPU. Replace it with xxHash64, which both already
exists in the codebase and is fairly fast.
Patch from Scott Smith!
Differential Revision: https://reviews.llvm.org/D32509
llvm-svn: 301487
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
Add a field indicating the associated check for every replacement to the YAML
report generated with the '-export-fixes' option. Update
clang-apply-replacements to handle the new format.
Patch by Alpha Abdoulaye!
Differential revision: https://reviews.llvm.org/D26137
llvm-svn: 290892
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
llvm-svn: 289618
While C(++) and ObjC are generally formatted the same way and can be
mixed, people might want to choose different styles based on the
language. This patch recognizes .m and .mm files as ObjC and also
implements a very crude detection of whether or not a .h file contains
ObjC code. This can be improved over time.
Also move most of the ObjC tests into their own test file to keep file
size maintainable.
llvm-svn: 289428
In bigger projects like an Operating System, the same source code is
often compiled in slightly different ways. This could be the difference
between PIC and non-PIC code for static vs dynamic libraries, it could
also be the difference between size optimised versions of tools for
ramdisk images. At the moment, the compilation database has no way to
distinguish such cases. As first step, add a field in the JSON format
for it and process it accordingly.
Differential Revision: https://reviews.llvm.org/D27138
llvm-svn: 288436
On Windows, Clang is mangling lambdas in default member initializers
incorrectly. See PR31197.
This is causing redness on the self-host bots. Work around the problem
locally so we aren't blind to further issues.
llvm-svn: 288089
Summary:
If the `FromDecl` is a class forward declaration, the reference is
still considered as referring to the original definition given the nature
of forward-declarations, so we can't do a raw name replacement in this case.
Reviewers: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D27132
llvm-svn: 287929
Summary:
For example, this case was missed when looking for different but canonical
namespaces. UseContext in this case should be considered as in the canonical
namespace.
```
namespace a { namespace b { <FromContext> } }
namespace a { namespace b { namespace c { <UseContext> } } }
```
Added some commenting.
Reviewers: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D27125
llvm-svn: 287924
Summary:
The new error information contains the type of error (e.g. overlap or bad file path)
and the replacement(s) that is causing the error. This enables us to resolve some errors.
For example, for insertion at the same location conflict, we need to know the
existing replacement which conflicts with the new replacement in order to calculate
the new position to be insert before/after the existing replacement (for merging).
Reviewers: klimek, bkramer
Subscribers: djasper, cfe-commits
Differential Revision: https://reviews.llvm.org/D26853
llvm-svn: 287639
Summary:
The current version does not deduplicate equivalent file paths correctly.
For example, a relative path and an absolute path are considered inequivalent.
Comparing FileEnry addresses these issues.
Reviewers: djasper
Subscribers: alexshap, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D26288
llvm-svn: 286096
Alex Lorenz