summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Tooling/RefactoringTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-271-3/+3
| | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 331069
* Revert "[Tooling] [0/1] Refactor FrontendActionFactory::create() to return ↵Roman Lebedev2018-02-271-1/+1
| | | | | | | | | | | | std::unique_ptr<>" This reverts commit rL326201 This broke gcc4.8 builds, compiler just segfaults:¬ http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/14909¬ http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/22673¬ llvm-svn: 326204
* [Tooling] [0/1] Refactor FrontendActionFactory::create() to return ↵Roman Lebedev2018-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | std::unique_ptr<> Summary: Noticed during review of D41102. I'm not sure whether there are any principal reasons why it returns raw owning pointer, or it is just a old code that was not updated post-C++11. I'm not too sure what testing i should do, because `check-all` is not error clean here for some reason, but it does not //appear// asif those failures are related to these changes. This is clang part. Clang-tools-extra part is D43780. Reviewers: klimek, bkramer, alexfh, pcc Reviewed By: alexfh Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D43779 llvm-svn: 326201
* Added `applyAtomicChanges` function.Eric Liu2017-07-311-0/+422
| | | | | | | | | | | | | | | | | | 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-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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-11/+12
| | | | | | | | | | | | 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-430/+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
* Revert "Try to unbreak buildbots after r298913."Juergen Ributzka2017-03-291-20/+28
| | | | llvm-svn: 298966
* Try to unbreak buildbots after r298913.Eric Liu2017-03-281-28/+20
| | | | llvm-svn: 298919
* Added `applyAtomicChanges` function.Eric Liu2017-03-281-0/+430
| | | | | | | | | | | | | | 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-2/+20
| | | | | | | | | | | | | | 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-4/+187
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make llvm::Error generated from replacement interfaces more specific.Eric Liu2016-11-221-19/+75
| | | | | | | | | | | | | | | | | Summary: The new error information contains the type of error (e.g. overlap or bad file path) and the replacement(s) that is causing the error. This enables us to resolve some errors. For example, for insertion at the same location conflict, we need to know the existing replacement which conflicts with the new replacement in order to calculate the new position to be insert before/after the existing replacement (for merging). Reviewers: klimek, bkramer Subscribers: djasper, cfe-commits Differential Revision: https://reviews.llvm.org/D26853 llvm-svn: 287639
* Fix memory leak caused by r286096.Eric Liu2016-11-071-6/+6
| | | | llvm-svn: 286132
* Deduplicate replacements by FileEntry instead of file names.Eric Liu2016-11-071-19/+44
| | | | | | | | | | | | | | | Summary: The current version does not deduplicate equivalent file paths correctly. For example, a relative path and an absolute path are considered inequivalent. Comparing FileEnry addresses these issues. Reviewers: djasper Subscribers: alexshap, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D26288 llvm-svn: 286096
* Try to fix windows bot file path style failure caused by r284219.Eric Liu2016-10-141-0/+18
| | | | llvm-svn: 284222
* Deduplicate sets of replacements by file names.Eric Liu2016-10-141-0/+18
| | | | | | | | | | | | | | | Summary: If there are multiple <File, Replacements> pairs with the same file path after removing dots, we only keep one pair (with path after dots being removed) and discard the rest. Reviewers: djasper Subscribers: klimek, hokein, bkramer, cfe-commits Differential Revision: https://reviews.llvm.org/D25565 llvm-svn: 284219
* Merge conflicting replacements when they are order-independent.Eric Liu2016-09-281-12/+180
| | | | | | | | | | | | | | | | | | | | | | Summary: Now two replacements are considered order-independent if applying them in either order produces the same result. These include (but not restricted to) replacements that: - don't overlap (being directly adjacent is fine) and - are overlapping deletions. - are insertions at the same offset and applying them in either order has the same effect, i.e. X + Y = Y + X if one inserts text X and the other inserts text Y. Discussion about this design can be found in D24717 Reviewers: djasper, klimek Subscribers: omtcyfz, cfe-commits Differential Revision: https://reviews.llvm.org/D24800 llvm-svn: 282577
* Recommit r281457 "Supports adding insertion around non-insertion replacements".Eric Liu2016-09-191-5/+83
| | | | | | | | | | | | | | Summary: Diff to r281457: - added a test case `CalculateRangesOfInsertionAroundReplacement`. Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D24606 llvm-svn: 281891
* Revert r281457 "Supports adding insertion around non-insertion replacements."Artem Belevich2016-09-141-72/+5
| | | | | | Commit was breaking our internal tests. llvm-svn: 281557
* Supports adding insertion around non-insertion replacements.Eric Liu2016-09-141-5/+72
| | | | | | | | | | | | | | | | | | | | Summary: Extend `tooling::Replacements::add()` to support adding order-independent replacements. Two replacements are considered order-independent if one of the following conditions is true: - They do not overlap. (This is already supported.) - One replacement is insertion, and the other is a replacement with length > 0, and the insertion is adjecent to but not contained in the other replacement. In this case, the replacement should always change the original code instead of the inserted text. Reviewers: klimek, djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D24515 llvm-svn: 281457
* Fixes calculateRangesAfterReplacements crash when Replacements is empty.Eric Liu2016-08-081-0/+7
| | | | | | | | | | Reviewers: klimek, djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D23264 llvm-svn: 278004
* Fix bug in conflict check for Replacements::add().Manuel Klimek2016-08-031-0/+20
| | | | | | | We would not detect conflicts when inserting insertions at the same offset as previously contained replacements. llvm-svn: 277603
* Fix quadratic runtime when adding items to tooling::Replacements.Manuel Klimek2016-08-031-0/+42
| | | | | | | | | | | Previously, we would search through all replacements when inserting a new one to check for overlaps. Instead, make use of the fact that we already have a set of replacments without overlaps to find the potential overlap with lower_bound. Differential Revision: https://reviews.llvm.org/D23119 llvm-svn: 277597
* Implement tooling::Replacements as a class.Eric Liu2016-08-011-250/+176
| | | | | | | | | | | | | | | | | | | Summary: - Implement clang::tooling::Replacements as a class to provide interfaces to control how replacements for a single file are combined and provide guarantee on the order of replacements being applied. - tooling::Replacements only contains replacements for the same file now. Use std::map<std::string, tooling::Replacements> to represent multi-file replacements. - Error handling for the interface change will be improved in followup patches. Reviewers: djasper, klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21748 llvm-svn: 277335
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* Make tooling::applyAllReplacements return llvm::Expected<string> instead of ↵Eric Liu2016-07-111-12/+17
| | | | | | | | | | | | | | | | empty string to indicate potential error. Summary: return llvm::Expected<> to carry error status and error information. This is the first step towards introducing "Error" into tooling::Replacements. Reviewers: djasper, klimek Subscribers: ioeric, klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D21601 llvm-svn: 275062
* Added calculateRangesAfterReplaments() to calculate affacted ranges in the ↵Eric Liu2016-06-211-4/+87
| | | | | | | | | | | | | | | | new code. Summary: Added calculateRangesAfterReplaments() to calculate original ranges as well as newly affacted ranges in the new code. Reviewers: klimek, djasper Subscribers: cfe-commits, klimek Differential Revision: http://reviews.llvm.org/D21547 llvm-svn: 273290
* Added formatAndApplyAllReplacements that works on multiple files in libTooling.Eric Liu2016-03-291-1/+35
| | | | | | | | | | | | | | Summary: formatAndApplyAllReplacements takes a set of Replacements, applies them on a Rewriter, and reformats the changed code. Reviewers: klimek, djasper Subscribers: ioeric, klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D17852 llvm-svn: 264745
* Add functions to apply replacements and reformat them.Manuel Klimek2016-03-011-0/+19
| | | | | | | | | | | | | | | | This is a commonly useful feature to have, and we have implemented it multiple times with different kinds of bugs. This implementation centralizes the idea in a set of functions that we can then use from the various tools. Reverts r262234, which is a revert of r262232, and puts the functions into FOrmat.h, as they are closely coupled to clang-format, and we otherwise introduce a cyclic dependency between libFormat and libTooling. Patch by Eric Liu. llvm-svn: 262323
* Revert "Implement new interfaces for code-formatting when applying ↵Manuel Klimek2016-02-291-49/+0
| | | | | | | | replacements." This reverts commit r262232. llvm-svn: 262234
* Implement new interfaces for code-formatting when applying replacements.Manuel Klimek2016-02-291-0/+49
| | | | | | Patch by Eric Liu. llvm-svn: 262232
* Fix calculation of shifted cursor/code positions. Specifically supportDaniel Jasper2015-11-231-6/+15
| | | | | | | | | the case where a specific range is replaced by new text. Previously, the calculation would shift any position from within a replaced region to the first character after the region. This is undersirable, e.g. for clang-format's include sorting. llvm-svn: 253859
* clang-format: Add initial #include sorting capabilities.Daniel Jasper2015-09-231-0/+93
| | | | | | | | | To implement this nicely, add a function that merges two sets of replacements that are meant to be done in sequence. This functionality will also be useful for other applications, e.g. formatting the result of clang-tidy fixes. llvm-svn: 248367
* Allow replacements created from token ranges to specify language options.Manuel Klimek2015-06-031-0/+25
| | | | | | | | The default language options will lead to incorrect replacements in C++ code, for example when trying to replace nested name specifiers ending in "::". llvm-svn: 238922
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix Reviewers: dblaikie Reviewed By: dblaikie Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D8926 llvm-svn: 234678
* Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue.David Blaikie2014-11-191-1/+2
| | | | llvm-svn: 222306
* Make VFS and FileManager match the current MemoryBuffer API.Benjamin Kramer2014-10-261-3/+2
| | | | | | | This eliminates converting back and forth between the 3 formats and gives us a more homogeneous interface. llvm-svn: 220657
* Tooling: Ignore file names in tooling::deduplicate.Benjamin Kramer2014-09-091-2/+6
| | | | | | | | | | | 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
* Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)David Blaikie2014-08-101-3/+4
| | | | | | | | 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
* Revert "unique_ptr-ify ownership of ASTConsumers"David Blaikie2014-07-171-4/+3
| | | | | | | | | 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
* unique_ptr-ify ownership of ASTConsumersDavid Blaikie2014-07-171-3/+4
| | | | | | | | | (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
* Replace llvm::error_code with std::error_code.Rafael Espindola2014-06-121-3/+2
| | | | llvm-svn: 210780
* [C++11] Use 'nullptr'. Unittests edition.Craig Topper2014-06-081-2/+2
| | | | llvm-svn: 210423
* Fix two test-only leaks found by LSan.Nico Weber2014-04-241-1/+3
| | | | | | | | | 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
* Reverted r192992 broke windows and freebsd builds.Ariel J. Bernal2013-10-181-46/+0
| | | | llvm-svn: 192997
* This patch fixes replacements that are not applied when relative paths areAriel J. Bernal2013-10-181-0/+46
| | | | | | | | | | specified. In particular it makes sure that relative paths for non-virtual files aren't made absolute. Added unittest. llvm-svn: 192992
* Revert commit r192299 until find a way to account for simlinks in OS X.Ariel J. Bernal2013-10-091-53/+0
| | | | llvm-svn: 192313
* This patch fixes replacements that are not applied when relative paths areAriel J. Bernal2013-10-091-0/+53
| | | | | | | | | | specified. In particular it makes sure that relative paths for non-virtual files aren't made absolute. Added unittest test. llvm-svn: 192299
* Adding a vector version of clang::tooling::shiftedCodePosition().Edwin Vane2013-08-271-0/+19
| | | | | | | | | 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
OpenPOWER on IntegriCloud