This moves classes for storing and applying replacements to separate
files. These classes specifically are used by clang-format which doesn't
have any other dependencies on clangAST. Thereby, the size of
clang-format's binary can be cut roughly in half and its build time sped
up.
llvm-svn: 220867
This was horribly broken due to how the sort predicate works. We would
report a conflict for files with a replacement in the same position but
different names if the length differed. Just ignore paths as this is often
what the user wants. Files can occur with different names (due to symlinks
or relative paths) and we don't ever want to do the same edit in one file
twice.
llvm-svn: 217439
Only those callers who are dynamically passing ownership should need the
3 argument form. Those accepting the default ("do pass ownership")
should do so explicitly with a unique_ptr now.
llvm-svn: 216614
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
This replaces the custom code in RefactoringTool::saveRewrittenFiles() which
lacked atomic file saving and error diagnostics, resolving an old FIXME from
r157331.
Landing this time with the proper return code, plus a very unhelpful comment
cleared up.
Rubber-stamped by Manuel Klimek.
llvm-svn: 193594
The old code in RefactoringTool::saveRewrittenFiles() lacked
atomic moves and diagnostics and had FIXME to this effect.
Rubber-stamped by Manuel Klimek.
llvm-svn: 193590
Replacements were no applied when using a compilation database with paths in the
compilation command relative to the compile directory. This patch makes those
paths abosulte.
llvm-svn: 191776
During the transition of clang::tooling::Replacements from std::set to
std::vector, functions such as clang::tooling::applyAllReplacements() have been
duplicated to take a std::vector<Replacement>. Applying this same temporary
duplication to clang::tooling::shiftedCodePosition().
llvm-svn: 189358
* Introduce operator< to replace Replacement::Less
* Make operator== and operator< on Replacements non-member functions
* Change order of comparisons in operator< to do string comparisons last
llvm-svn: 188550
One day soon, tooling::Replacements will be changed from being implemented as
an std::set to being implemented as an std::vector. Until then, some new code
using vectors of Replacements would enjoy having a version of
applyAllReplacements that takes a vector.
Differential Revision: http://llvm-reviews.chandlerc.com/D1380
llvm-svn: 188295
If a Replacment is contained within the conflict range being built, the
conflict range would be erroneously shortened. Now fixed. Tests updated to
catch this case.
llvm-svn: 188287
Summary:
This patch adds tooling::deduplicate() which removes duplicates from and
looks for conflicts in a vector of Replacements.
Differential Revision: http://llvm-reviews.chandlerc.com/D1314
llvm-svn: 187979
With this patch, clang-format will try to keep the cursor at the
original code position in editor integrations (implemented for emacs and
vim). This means, after formatting, clang-format will try to keep the
cursor on the same character of the same token.
llvm-svn: 182373
It turns out that several implementations go through the trouble of
setting up a SourceManager and Lexer and abstracting this into a
function makes usage easier.
Also abstracts SourceManager-independent ranges out of
tooling::Refactoring and provides a convenience function to create them
from line ranges.
llvm-svn: 181997
RefactoringTool::run() always writes the result of rewrites to disk.
Instead, make this optional and provide a method for getting the
refactoring results in a memory buffer instead.
Also made ClangTool polymorphic so RefactoringTool could inherit from it
to properly express the IS-A relationship. This change also provides
access to ClangTool's public interface, e.g. mapVirtualFile() which is
important once refactored buffers start living in memory instead of on
disk.
Reviewers: klimek
llvm-svn: 172219
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
llvm-svn: 166508
This is similar to how we divide up the StaticAnalyzer libraries to separate
core functionality to what is clearly associated with Frontend actions.
llvm-svn: 163050
Daniel Jasper