Summary:
In D33899, I'm adding a `raw_ostream &` parameter to the function
objects passed to `cl::SetVersionPrinter`. Adjust the call in
clang-apply-replacements for this.
Reviewers: klimek, alexfh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33959
llvm-svn: 304837
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: 290893
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"Now I am become Death, the destroyer of worlds."
-J. Robert Oppenheimer
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D16475
llvm-svn: 258864
in r253859 makes sense in many cases and thus, I have fixed the
implementation of calculateChangedRanges instead. It had a FIXME anyway
saying that it was unecessarily using shiftedCodePosition which
resulted in O(N^2) runtime.
llvm-svn: 253929
clangApplyReplacements.lib(ApplyReplacements.cpp.obj) : error LNK2001: unresolved external symbol "private: void __thiscall clang::APValue::DestroyDataAndMakeUninit(void)" (?DestroyDataAndMakeUninit@APValue@clang@@AAEXXZ)
They are not seen in mingw dll build. Investigating.
llvm-svn: 220895
Bucket replacements by FileEntry instead of path. The same file with
different paths is very common, relative #include paths and symlinks can
easily create them. When that occurs we would apply the fix twice.
llvm-svn: 217440
This removes all references to OwningPtr, which should be fairly
undisruptive to out-of-tree projects since they are unlikely to use
clang-tools-extra as a library instead of a set of tools.
llvm-svn: 203382
always produce as pretty of results as it does in LLVM and Clang, but
I don't mind and the value of having a single canonical ordering is very
high IMO.
Let me know if you spot really serious problems here.
llvm-svn: 198703
Summary:
The clang-apply-replacements process is now invoked to apply
replacements between applying transforms. This resulted in a massive
simplification of the tool:
- FileOverrides class no longer needed.
- Change tracking and code formatting no longer needed.
- No more dependency on libclangApplyReplacements.
- Final syntax check is easier to do directly now than with a separate
header/source pair.
Replacement handling stuff abstracted into a new header/source pair to
de-clutter ClangModernize.cpp somewhat.
Tests updated.
Differential Revision: http://llvm-reviews.chandlerc.com/D1836
llvm-svn: 192032
The tool now supports a collection of arguments to turn on and provide settings
for the formatting of code affected by applying replacements:
* --format turns on formatting (default style is LLVM)
* --style controls code style settings
* --style-config allows one to explicitly indicate where a style config file
lives.
The libclangApplyReplacements interface has a new function to turn Replacements
into Ranges to be used with tooling::reformat().
llvm-svn: 191667
Options that leak from other parts of LLVM are now pruned out of -help.
-version output is specific to clang-apply-replacements now.
Differential Revision: http://llvm-reviews.chandlerc.com/D1747
llvm-svn: 191322
Dimitry Andric