summaryrefslogtreecommitdiffstats
path: root/clang/lib/Tooling/Refactoring/AtomicChange.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Added `applyAtomicChanges` function.Eric Liu2017-07-311-0/+179
| | | | | | | | | | | | | | | | | | This re-commits r298913. o See thread http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170327/189084.html o Tested with -DLLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=0. Summary: ... which applies a set of `AtomicChange`s on code. Reviewers: klimek, djasper Reviewed By: djasper Subscribers: arphaman, mgorny, chapuni, cfe-commits Differential Revision: https://reviews.llvm.org/D30777 llvm-svn: 309548
* Fix ODR violations due to abuse of LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTORRichard Smith2017-06-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Add `replace` interface with range in AtomicChange.Haojian Wu2017-03-301-0/+6
| | | | | | | | | | | | Reviewers: ioeric Reviewed By: ioeric Subscribers: alexshap, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D31492 llvm-svn: 299073
* Revert "Added `applyAtomicChanges` function."Juergen Ributzka2017-03-291-179/+0
| | | | | | | | | This broke GreenDragon: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA_build/4776/ Reverting this commit and all follow-up commits. llvm-svn: 298967
* Added `applyAtomicChanges` function.Eric Liu2017-03-281-0/+179
| | | | | | | | | | | | | | 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
* Add missing implementation for AtomicChange::replace(...)Eric Liu2017-03-081-0/+5
| | | | | | | | | | | | | | Summary: Just realized the implementation is missing... Reviewers: klimek Reviewed By: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30735 llvm-svn: 297289
* Introducing clang::tooling::AtomicChange for refactoring tools.Eric Liu2017-03-011-0/+167
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
OpenPOWER on IntegriCloud