Although it is not explicitly stated in LLVM Coding Standards, LLVM developers
prefer to omit braces around flow control statements with single line body.
For example the following piece of code
```
if (condition)
std::cout << "Hello, world!" << std::endl;
```
is preferred to
```
if (condition) {
std::cout << "Hello, world!" << std::endl;
}
```
So far clang-rename has ignored this. This patch makes clang-rename more
"LLVM-ish".
llvm-svn: 280640
As Alexander pointed out, LLVM Coding Standards are more conservative about
using auto, i.e. it should be used in the following situations:
* When the type is obvious, i.e. explicitly mentioned in the same expression.
For example `if (const clang::FieldDecl *FieldDecl = Initializer->getMember())`.
* When the type is totally non-obvious and one iterates over something. For
example
`for (const auto &CurrDecl : Context.getTranslationUnitDecl()->decls())`.
Otherwise the type should be explicitly stated.
Reviewers: alexfh
Differential Revision: https://reviews.llvm.org/D23397
llvm-svn: 278760
- rename-at is meant to be integrated with editors and works mainly off
of a location in a file, and this is the default
- rename-all is optimized for one or more oldname->newname renames, and
works with clang-apply-replacements
Reviewers: bkramer, klimek
Subscribers: omtcyfz
Differential Revision: https://reviews.llvm.org/D21814
llvm-svn: 277438
The complexity of renaming a USR is O(N) [N stands for number of nodes in
Translation Unit]. In some cases there are more than one USR for a single symbol
(see overridden functions and ctor/dtor handling), which means that the
complexity of finding all of the corresponding USRs is O(N * M) [M stands for
number of USRs corresponding to the symbols, which may be not quite small]. With
a simple tweak we can make it O(N * log(M)) by passing whole list of USRs
corresponding to the symbol to USRLocFinder.
llvm-svn: 277131
This patch introduces:
* TypeLoc visiting, which helps a lot in renaming types
* NestedNameSpecifierLoc visiting (through getting them via ASTMatcher at the moment, though, because RecursiveASTVisitor<T>::VisitNestedNameSpecifierLoc isn't implemented), which helps to treat nested names correctly
* better code formatting and refactoring
* bunch of tests
Reviewers: alexfh
Differential revision: https://reviews.llvm.org/D22465
llvm-svn: 276414
This patch does the following:
* enforces proper formatting for few files (i.e. deals with 80 linewidth violations and few other things)
* ensures '\n' chars are passed to the output streams instead of "\n" strings
* fixes a bug caused by calling cl::PrintHelpMessage(), which occasionally calls exit(0), so that exit(1) (which is right after cl::PrintHelpMessage line) becomes dead code
Patch by Kirill Bobyrev!
Differential Revision: http://reviews.llvm.org/D22091
llvm-svn: 275387
This more general check could have prevented the specific problem
"getSourceOrder() == -1" guards.
Reviewers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D20216
llvm-svn: 269402
Summary:
Note that this code is still grossly under-tested - the next steps will
be to add significantly better test coverage.
Patch by Matthew Plant.
Test Plan:
Reviewers:
Subscribers:
llvm-svn: 215839