| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 222306
|
|
|
|
|
|
|
| |
This eliminates converting back and forth between the 3 formats and
gives us a more homogeneous interface.
llvm-svn: 220657
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
llvm-svn: 215323
|
|
|
|
|
|
|
|
|
| |
This reverts commit r213307.
Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.
llvm-svn: 213325
|
|
|
|
|
|
|
|
|
| |
(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)
llvm-svn: 213307
|
|
|
|
| |
llvm-svn: 210780
|
|
|
|
| |
llvm-svn: 210423
|
|
|
|
|
|
|
|
|
| |
The result of getBufferForFile() must be freed.
(Should we change functions that expect the caller to assume ownership so
that they return unique_ptrs instead? Then the type system makes sure we get
this right.)
llvm-svn: 207074
|
|
|
|
| |
llvm-svn: 192997
|
|
|
|
|
|
|
|
|
|
| |
specified.
In particular it makes sure that relative paths for non-virtual files aren't
made absolute.
Added unittest.
llvm-svn: 192992
|
|
|
|
| |
llvm-svn: 192313
|
|
|
|
|
|
|
|
|
|
| |
specified.
In particular it makes sure that relative paths for non-virtual files aren't
made absolute.
Added unittest test.
llvm-svn: 192299
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Improved test to catch missing case.
llvm-svn: 188304
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Guillaume Papin.
llvm-svn: 186670
|
|
|
|
| |
llvm-svn: 185717
|
|
|
|
|
|
|
| |
Instead of creating a temporary directory, remember the set of temporary files
we create.
llvm-svn: 184951
|
|
|
|
| |
llvm-svn: 183786
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
| |
I've tried to place sensible headers at the top as main-module headers.
llvm-svn: 169243
|
|
|
|
| |
llvm-svn: 166516
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 159724
|
|
that allows easy refactoring across translation units.
llvm-svn: 157331
|