aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/Tooling/RefactoringTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2 daysNFC: Clean up construction of IntrusiveRefCntPtr from raw pointers for ↵James Y Knight1-6/+3
llvm::vfs::FileSystem. (#151407) This switches to `makeIntrusiveRefCnt<FileSystem>` where creating a new object, and to passing/returning by `IntrusiveRefCntPtr<FileSystem>` instead of `FileSystem*` or `FileSystem&`, when dealing with existing objects. Part of cleanup #151026.
2025-07-18[Clang][AST][NFC] Introduce `NamespaceBaseDecl` (#149123)Yanzuo Liu1-1/+2
Add `NamespaceBaseDecl` as common base class of `NamespaceDecl` and `NamespaceAliasDecl`. This simplifies `NestedNameSpecifier` a bit. Co-authored-by: Matheus Izvekov <mizvekov@gmail.com>
2024-11-15[Clang] [Tests] Refactor most unit tests to use DynamicRecursiveASTVisitor ↵Sirraide1-12/+9
(#115132) This pr refactors most tests that use RAV to use DRAV instead; this also has the nice effect of testing both the RAV and DRAV implementations at the same time w/o having to duplicate all of our AST visitor tests. Some tests rely on features that DRAV doesn’t support (mainly post-order traversal), so those haven’t been migrated. At the same time, `TestVisitor` is now a DRAV, so I’ve had to introduce a new `CTRPTestVisitor` for any tests that need to use RAV directly.
2024-09-14[clang] Strip unneeded calls to raw_string_ostream::str() (NFC)JOE19941-1/+0
Avoid extra layer of indirection. p.s. Also, remove calls to raw_string_ostream::flush(), which are no-ops.
2023-01-14[clang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata1-2/+2
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14[clang] Add #include <optional> (NFC)Kazu Hirata1-0/+1
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-20[llvm] Make llvm::Any similar to std::anySebastian Neubauer1-1/+1
This facilitates replacing llvm::Any with std::any. - Deprecate any_isa in favor of using any_cast(Any*) and checking for nullptr because C++17 has no any_isa. - Remove the assert from any_cast(Any*), so it returns nullptr if the type is not correct. This aligns it with std::any_cast(any*). Use any_cast(Any*) throughout LLVM instead of checks with any_isa. This is the first part outlined in https://discourse.llvm.org/t/rfc-switching-from-llvm-any-to-std-any/67176 Differential Revision: https://reviews.llvm.org/D139973
2022-08-20[clang] Use Any::has_value instead of Any::hasValue (NFC)Kazu Hirata1-1/+1
2022-06-25[clang] Don't use Optional::hasValue (NFC)Kazu Hirata1-4/+4
This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata1-4/+4
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata1-4/+4
2021-10-29Support: Use sys::path::is_style_{posix,windows}() in a few placesDuncan P. N. Exon Smith1-21/+10
Use the new sys::path::is_style_posix() and is_style_windows() in a few places that need to detect the system's native path style. In llvm/lib/Support/Path.cpp, this patch removes most uses of the private `real_style()`, where is_style_posix() and is_style_windows() are just a little tidier. Elsewhere, this removes `_WIN32` macro checks. Added a FIXME to a FileManagerTest that seemed fishy, but maintained the existing behaviour. Differential Revision: https://reviews.llvm.org/D112289
2020-12-10Tooling: Migrate some tests to FileEntryRef, NFCDuncan P. N. Exon Smith1-1/+1
Migrate to the `FileEntryRef` overload of `SourceManager::createFileID` (using `FileManager::getOptionalFileRef`) in RefactoringTest.cpp and RewriterTestContext.h. No functionality change. Differential Revision: https://reviews.llvm.org/D92967
2020-06-30Add Metadata to Transformer toolingAndy Soffer1-0/+12
This change adds a Metadata field to ASTEdit, Edit, and AtomicChange so that edits can have associated metadata and that metadata can be constructed with Transformer-based RewriteRules. Metadata is ignored when applying edits to source, but other consumers of AtomicChange can use this metadata to direct how they want to consume each edit. Reviewed By: ymandel, gribozavr2 Differential Revision: https://reviews.llvm.org/D82226
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-11/+12
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2019-08-30[Tooling] Migrated APIs that take ownership of objects to unique_ptrDmitri Gribenko1-1/+1
Subscribers: jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66960 llvm-svn: 370451
2019-08-14[Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-1/+1
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
2019-08-01[clang] Adopt new FileManager error-returning APIsHarlan Haskins1-3/+4
Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods. Signed-off-by: Harlan Haskins <harlan@apple.com> llvm-svn: 367616
2019-07-12[test] Delete trailing spaces from YAML testsFangrui Song1-6/+6
llvm-svn: 365873
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-10-10Lift VFS from clang to llvm (NFC)Jonas Devlieghere1-8/+8
This patch moves the virtual file system form clang to llvm so it can be used by more projects. Concretely the patch: - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support. - Moves the corresponding unit test from clang to llvm. - Moves the vfs namespace from clang::vfs to llvm::vfs. - Formats the lines affected by this change, mostly this is the result of the added llvm namespace. RFC on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html Differential revision: https://reviews.llvm.org/D52783 llvm-svn: 344140
2018-04-27s/LLVM_ON_WIN32/_WIN32/, clangNico Weber1-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
2018-02-27Revert "[Tooling] [0/1] Refactor FrontendActionFactory::create() to return ↵Roman Lebedev1-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
2018-02-27[Tooling] [0/1] Refactor FrontendActionFactory::create() to return ↵Roman Lebedev1-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
2017-07-31Added `applyAtomicChanges` function.Eric Liu1-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
2017-06-30Fix ODR violations due to abuse of LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTORRichard Smith1-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
2017-03-30Add `replace` interface with range in AtomicChange.Haojian Wu1-11/+12
Reviewers: ioeric Reviewed By: ioeric Subscribers: alexshap, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D31492 llvm-svn: 299073
2017-03-29Revert "Added `applyAtomicChanges` function."Juergen Ributzka1-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
2017-03-29Revert "Try to unbreak buildbots after r298913."Juergen Ributzka1-20/+28
llvm-svn: 298966
2017-03-28Try to unbreak buildbots after r298913.Eric Liu1-28/+20
llvm-svn: 298919
2017-03-28Added `applyAtomicChanges` function.Eric Liu1-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
2017-03-08Add missing implementation for AtomicChange::replace(...)Eric Liu1-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
2017-03-01Introducing clang::tooling::AtomicChange for refactoring tools.Eric Liu1-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
2016-11-22Make llvm::Error generated from replacement interfaces more specific.Eric Liu1-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
2016-11-07Fix memory leak caused by r286096.Eric Liu1-6/+6
llvm-svn: 286132
2016-11-07Deduplicate replacements by FileEntry instead of file names.Eric Liu1-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
2016-10-14Try to fix windows bot file path style failure caused by r284219.Eric Liu1-0/+18
llvm-svn: 284222
2016-10-14Deduplicate sets of replacements by file names.Eric Liu1-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
2016-09-28Merge conflicting replacements when they are order-independent.Eric Liu1-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
2016-09-19Recommit r281457 "Supports adding insertion around non-insertion replacements".Eric Liu1-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
2016-09-14Revert r281457 "Supports adding insertion around non-insertion replacements."Artem Belevich1-72/+5
Commit was breaking our internal tests. llvm-svn: 281557
2016-09-14Supports adding insertion around non-insertion replacements.Eric Liu1-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
2016-08-08Fixes calculateRangesAfterReplacements crash when Replacements is empty.Eric Liu1-0/+7
Reviewers: klimek, djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D23264 llvm-svn: 278004
2016-08-03Fix bug in conflict check for Replacements::add().Manuel Klimek1-0/+20
We would not detect conflicts when inserting insertions at the same offset as previously contained replacements. llvm-svn: 277603
2016-08-03Fix quadratic runtime when adding items to tooling::Replacements.Manuel Klimek1-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
2016-08-01Implement tooling::Replacements as a class.Eric Liu1-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
2016-07-18[NFC] Header cleanupMehdi Amini1-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
2016-07-11Make tooling::applyAllReplacements return llvm::Expected<string> instead of ↵Eric Liu1-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
2016-06-21Added calculateRangesAfterReplaments() to calculate affacted ranges in the ↵Eric Liu1-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
2016-03-29Added formatAndApplyAllReplacements that works on multiple files in libTooling.Eric Liu1-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