mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-05-03 11:36:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

429 lines
13 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:23:27 +01:00
//===-- LibStdcpp.cpp -----------------------------------------------------===//
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 08:50:56 +00:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
//
//===----------------------------------------------------------------------===//
Move the C++ data formatters to the C++ language plugin llvm-svn: 246873
2015-09-04 21:01:18 +00:00
#include "LibStdcpp.h"
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
[lldb] Move clang-based files out of Symbol Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h This explicitly removes knowledge of clang internals from lldbSymbol, moving towards a more generic core implementation of lldb. Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73661
2020-01-29 11:59:28 -08:00
#include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
#include "lldb/Core/ValueObject.h"
#include "lldb/Core/ValueObjectConstResult.h"
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
#include "lldb/DataFormatters/StringPrinter.h"
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
#include "lldb/DataFormatters/VectorIterator.h"
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
#include "lldb/Target/Target.h"
Move DataBuffer / DataExtractor and friends from Core -> Utility. llvm-svn: 296943
2017-03-04 01:30:05 +00:00
#include "lldb/Utility/DataBufferHeap.h"
Remove dependencies from Utility to Core and Target. With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
2017-02-14 19:06:07 +00:00
#include "lldb/Utility/Endian.h"
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
#include "lldb/Utility/Status.h"
Move classes from Core -> Utility. This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2017-02-02 21:39:50 +00:00
#include "lldb/Utility/Stream.h"
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::formatters;
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
namespace {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
class LibstdcppMapIteratorSyntheticFrontEnd : public SyntheticChildrenFrontEnd {
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
/*
(std::_Rb_tree_iterator<std::pair<const int, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >) ibeg = {
(_Base_ptr) _M_node = 0x0000000100103910 {
(std::_Rb_tree_color) _M_color = _S_black
(std::_Rb_tree_node_base::_Base_ptr) _M_parent = 0x00000001001038c0
(std::_Rb_tree_node_base::_Base_ptr) _M_left = 0x0000000000000000
(std::_Rb_tree_node_base::_Base_ptr) _M_right = 0x0000000000000000
}
}
*/
Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other minor fixes. llvm-svn: 262246
2016-02-29 19:41:30 +00:00
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
public:
explicit LibstdcppMapIteratorSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
size_t CalculateNumChildren() override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
lldb::ValueObjectSP GetChildAtIndex(size_t idx) override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
bool Update() override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
bool MightHaveChildren() override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Pass ConstString by value (NFC) My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-03-06 21:22:25 +00:00
size_t GetIndexOfChildWithName(ConstString name) override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
private:
ExecutionContextRef m_exe_ctx_ref;
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-14 13:32:03 -07:00
lldb::addr_t m_pair_address = 0;
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
CompilerType m_pair_type;
lldb::ValueObjectSP m_pair_sp;
};
Revert "Improve the libstdc++ smart pointer formatters" This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
2016-10-25 13:24:53 +00:00
class LibStdcppSharedPtrSyntheticFrontEnd : public SyntheticChildrenFrontEnd {
public:
explicit LibStdcppSharedPtrSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp);
size_t CalculateNumChildren() override;
lldb::ValueObjectSP GetChildAtIndex(size_t idx) override;
bool Update() override;
bool MightHaveChildren() override;
Pass ConstString by value (NFC) My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-03-06 21:22:25 +00:00
size_t GetIndexOfChildWithName(ConstString name) override;
Revert "Improve the libstdc++ smart pointer formatters" This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
2016-10-25 13:24:53 +00:00
};
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
} // end of anonymous namespace
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
LibstdcppMapIteratorSyntheticFrontEnd::LibstdcppMapIteratorSyntheticFrontEnd(
lldb::ValueObjectSP valobj_sp)
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2022-03-14 13:32:03 -07:00
: SyntheticChildrenFrontEnd(*valobj_sp), m_exe_ctx_ref(), m_pair_type(),
m_pair_sp() {
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
if (valobj_sp)
Update();
}
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
bool LibstdcppMapIteratorSyntheticFrontEnd::Update() {
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
ValueObjectSP valobj_sp = m_backend.GetSP();
if (!valobj_sp)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
TargetSP target_sp(valobj_sp->GetTargetSP());
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
if (!target_sp)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
bool is_64bit = (target_sp->GetArchitecture().GetAddressByteSize() == 8);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
if (!valobj_sp)
return false;
m_exe_ctx_ref = valobj_sp->GetExecutionContextRef();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
ValueObjectSP _M_node_sp(
valobj_sp->GetChildMemberWithName(ConstString("_M_node"), true));
if (!_M_node_sp)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
m_pair_address = _M_node_sp->GetValueAsUnsigned(0);
if (m_pair_address == 0)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
m_pair_address += (is_64bit ? 32 : 16);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-24 23:46:31 +00:00
CompilerType my_type(valobj_sp->GetCompilerType());
Convert GetNumTemplateArguments() and GetTemplateArgument() to be instance functions on the CompilerType and the TypeSystem llvm-svn: 244846
2015-08-13 00:24:24 +00:00
if (my_type.GetNumTemplateArguments() >= 1) {
CompilerType: Add ability to retrieve an integral template argument Summary: Despite it's name, GetTemplateArgument was only really working for Type template arguments. This adds the ability to retrieve integral arguments as well (which I've needed for the std::bitset data formatter). I've done this by splitting the function into three pieces. The idea is that one first calls GetTemplateArgumentKind (first function) to determine the what kind of a parameter this is. Based on that, one can then use specialized functions to retrieve the correct value. Currently, I only implement two of these: GetTypeTemplateArgument and GetIntegralTemplateArgument. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D39844 llvm-svn: 318040
2017-11-13 14:26:21 +00:00
CompilerType pair_type = my_type.GetTypeTemplateArgument(0);
if (!pair_type)
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
return false;
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-11 22:46:58 +00:00
m_pair_type = pair_type;
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
} else
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
return true;
}
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
size_t LibstdcppMapIteratorSyntheticFrontEnd::CalculateNumChildren() {
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
return 2;
}
lldb::ValueObjectSP
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
LibstdcppMapIteratorSyntheticFrontEnd::GetChildAtIndex(size_t idx) {
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-11 22:46:58 +00:00
if (m_pair_address != 0 && m_pair_type) {
if (!m_pair_sp)
This patch does a few things: - adds a new flag to mark ValueObjects as "synthetic children generated" - vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically - moves synthetic child providers over to using these new functions No visible feature change, but preparatory work for feature change llvm-svn: 223819
2014-12-09 19:51:20 +00:00
m_pair_sp = CreateValueObjectFromAddress("pair", m_pair_address,
m_exe_ctx_ref, m_pair_type);
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-11 22:46:58 +00:00
if (m_pair_sp)
return m_pair_sp->GetChildAtIndex(idx, true);
}
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
return lldb::ValueObjectSP();
}
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
bool LibstdcppMapIteratorSyntheticFrontEnd::MightHaveChildren() { return true; }
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
Nuke CXXFormatterFunctions.cpp - split the contents of it across different files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
2015-09-04 00:33:51 +00:00
size_t LibstdcppMapIteratorSyntheticFrontEnd::GetIndexOfChildWithName(
Pass ConstString by value (NFC) My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-03-06 21:22:25 +00:00
ConstString name) {
Allow direct comparison of ConstString against StringRef Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
2019-04-26 07:21:36 +00:00
if (name == "first")
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
return 0;
Allow direct comparison of ConstString against StringRef Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
2019-04-26 07:21:36 +00:00
if (name == "second")
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
return 1;
return UINT32_MAX;
}
SyntheticChildrenFrontEnd *
lldb_private::formatters::LibstdcppMapIteratorSyntheticFrontEndCreator(
CXXSyntheticChildren *, lldb::ValueObjectSP valobj_sp) {
Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other minor fixes. llvm-svn: 262246
2016-02-29 19:41:30 +00:00
return (valobj_sp ? new LibstdcppMapIteratorSyntheticFrontEnd(valobj_sp)
: nullptr);
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
}
/*
(lldb) fr var ibeg --ptr-depth 1
(__gnu_cxx::__normal_iterator<int *, std::vector<int, std::allocator<int> > >)
ibeg = {
_M_current = 0x00000001001037a0 {
*_M_current = 1
}
}
*/
SyntheticChildrenFrontEnd *
lldb_private::formatters::LibStdcppVectorIteratorSyntheticFrontEndCreator(
CXXSyntheticChildren *, lldb::ValueObjectSP valobj_sp) {
static ConstString g_item_name;
if (!g_item_name)
g_item_name.SetCString("_M_current");
Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other minor fixes. llvm-svn: 262246
2016-02-29 19:41:30 +00:00
return (valobj_sp
? new VectorIteratorSyntheticFrontEnd(valobj_sp, g_item_name)
: nullptr);
<rdar://problem/4529976> Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp) This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful llvm-svn: 175787
2013-02-21 19:57:10 +00:00
}
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
lldb_private::formatters::VectorIteratorSyntheticFrontEnd::
VectorIteratorSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp,
ConstString item_name)
Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other minor fixes. llvm-svn: 262246
2016-02-29 19:41:30 +00:00
: SyntheticChildrenFrontEnd(*valobj_sp), m_exe_ctx_ref(),
m_item_name(item_name), m_item_sp() {
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
if (valobj_sp)
Update();
}
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
bool VectorIteratorSyntheticFrontEnd::Update() {
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
m_item_sp.reset();
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
ValueObjectSP valobj_sp = m_backend.GetSP();
if (!valobj_sp)
return false;
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
if (!valobj_sp)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
ValueObjectSP item_ptr(valobj_sp->GetChildMemberWithName(m_item_name, true));
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
if (!item_ptr)
return false;
if (item_ptr->GetValueAsUnsigned(0) == 0)
return false;
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status err;
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
m_exe_ctx_ref = valobj_sp->GetExecutionContextRef();
m_item_sp = CreateValueObjectFromAddress(
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
"item", item_ptr->GetValueAsUnsigned(0), m_exe_ctx_ref,
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
item_ptr->GetCompilerType().GetPointeeType());
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
if (err.Fail())
m_item_sp.reset();
return false;
}
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
size_t VectorIteratorSyntheticFrontEnd::CalculateNumChildren() { return 1; }
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
lldb::ValueObjectSP
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
VectorIteratorSyntheticFrontEnd::GetChildAtIndex(size_t idx) {
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
if (idx == 0)
return m_item_sp;
return lldb::ValueObjectSP();
}
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
bool VectorIteratorSyntheticFrontEnd::MightHaveChildren() { return true; }
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
Add data formatter for libstdc++ shared_ptr and weak_ptr Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
2016-07-06 09:50:00 +00:00
size_t VectorIteratorSyntheticFrontEnd::GetIndexOfChildWithName(
Pass ConstString by value (NFC) My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-03-06 21:22:25 +00:00
ConstString name) {
Allow direct comparison of ConstString against StringRef Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
2019-04-26 07:21:36 +00:00
if (name == "item")
CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
2015-09-03 01:29:42 +00:00
return 0;
return UINT32_MAX;
}
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
bool lldb_private::formatters::LibStdcppStringSummaryProvider(
ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
const bool scalar_is_load_addr = true;
AddressType addr_type;
lldb::addr_t addr_of_string =
valobj.GetAddressOf(scalar_is_load_addr, &addr_type);
if (addr_of_string != LLDB_INVALID_ADDRESS) {
switch (addr_type) {
case eAddressTypeLoad: {
ProcessSP process_sp(valobj.GetProcessSP());
if (!process_sp)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
StringPrinter::ReadStringAndDumpToStreamOptions options(valobj);
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status error;
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
lldb::addr_t addr_of_data =
process_sp->ReadPointerFromMemory(addr_of_string, error);
if (error.Fail() || addr_of_data == 0 ||
addr_of_data == LLDB_INVALID_ADDRESS)
return false;
options.SetLocation(addr_of_data);
[lldb] (Partially) enable formatting of utf strings before the program is started The StringPrinter class was using a Process instance to read memory. This automatically prevented it from working before starting the program. This patch changes the class to use the Target object for reading memory, as targets are always available. This required moving ReadStringFromMemory from Process to Target. This is sufficient to make frame/target variable work, but further changes are necessary for the expression evaluator. Preliminary analysis indicates the failures are due to the expression result ValueObjects failing to provide an address, presumably because we're operating on file addresses before starting. I haven't looked into what would it take to make that work. Differential Revision: https://reviews.llvm.org/D113098
2021-11-03 13:43:33 +01:00
options.SetTargetSP(valobj.GetTargetSP());
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
options.SetStream(&stream);
options.SetNeedsZeroTermination(false);
options.SetBinaryZeroIsTerminator(true);
lldb::addr_t size_of_data = process_sp->ReadPointerFromMemory(
addr_of_string + process_sp->GetAddressByteSize(), error);
if (error.Fail())
return false;
options.SetSourceSize(size_of_data);
Reland [lldb] Fix string summary of an empty NSPathStore2 (This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix the Debian tests). Summary: Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888). It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings. This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly was the original purpose of this magic value). Reviewers: aprantl, JDevlieghere, shafik Reviewed By: aprantl Subscribers: christof, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68010
2020-03-19 12:20:18 +01:00
options.SetHasSourceSize(true);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
if (!StringPrinter::ReadStringAndDumpToStream<
StringPrinter::StringElementType::UTF8>(options)) {
stream.Printf("Summary Unavailable");
return true;
} else
return true;
} break;
case eAddressTypeHost:
break;
case eAddressTypeInvalid:
case eAddressTypeFile:
break;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
}
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
return false;
}
bool lldb_private::formatters::LibStdcppWStringSummaryProvider(
ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
const bool scalar_is_load_addr = true;
AddressType addr_type;
lldb::addr_t addr_of_string =
valobj.GetAddressOf(scalar_is_load_addr, &addr_type);
if (addr_of_string != LLDB_INVALID_ADDRESS) {
switch (addr_type) {
case eAddressTypeLoad: {
ProcessSP process_sp(valobj.GetProcessSP());
if (!process_sp)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
CompilerType wchar_compiler_type =
valobj.GetCompilerType().GetBasicTypeFromAST(lldb::eBasicTypeWChar);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
if (!wchar_compiler_type)
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-15 18:07:52 +00:00
// Safe to pass nullptr for exe_scope here.
Replace auto -> llvm::Optional<uint64_t> This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
2019-01-15 20:33:58 +00:00
llvm::Optional<uint64_t> size = wchar_compiler_type.GetBitSize(nullptr);
Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
2019-01-15 18:07:52 +00:00
if (!size)
return false;
const uint32_t wchar_size = *size;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
StringPrinter::ReadStringAndDumpToStreamOptions options(valobj);
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status error;
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
lldb::addr_t addr_of_data =
process_sp->ReadPointerFromMemory(addr_of_string, error);
if (error.Fail() || addr_of_data == 0 ||
addr_of_data == LLDB_INVALID_ADDRESS)
return false;
options.SetLocation(addr_of_data);
[lldb] (Partially) enable formatting of utf strings before the program is started The StringPrinter class was using a Process instance to read memory. This automatically prevented it from working before starting the program. This patch changes the class to use the Target object for reading memory, as targets are always available. This required moving ReadStringFromMemory from Process to Target. This is sufficient to make frame/target variable work, but further changes are necessary for the expression evaluator. Preliminary analysis indicates the failures are due to the expression result ValueObjects failing to provide an address, presumably because we're operating on file addresses before starting. I haven't looked into what would it take to make that work. Differential Revision: https://reviews.llvm.org/D113098
2021-11-03 13:43:33 +01:00
options.SetTargetSP(valobj.GetTargetSP());
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
options.SetStream(&stream);
options.SetNeedsZeroTermination(false);
options.SetBinaryZeroIsTerminator(false);
lldb::addr_t size_of_data = process_sp->ReadPointerFromMemory(
addr_of_string + process_sp->GetAddressByteSize(), error);
if (error.Fail())
return false;
options.SetSourceSize(size_of_data);
Reland [lldb] Fix string summary of an empty NSPathStore2 (This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix the Debian tests). Summary: Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888). It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings. This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly was the original purpose of this magic value). Reviewers: aprantl, JDevlieghere, shafik Reviewed By: aprantl Subscribers: christof, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68010
2020-03-19 12:20:18 +01:00
options.SetHasSourceSize(true);
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
options.SetPrefixToken("L");
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
switch (wchar_size) {
case 8:
return StringPrinter::ReadStringAndDumpToStream<
StringPrinter::StringElementType::UTF8>(options);
case 16:
return StringPrinter::ReadStringAndDumpToStream<
StringPrinter::StringElementType::UTF16>(options);
case 32:
return StringPrinter::ReadStringAndDumpToStream<
StringPrinter::StringElementType::UTF32>(options);
default:
stream.Printf("size for wchar_t is not valid");
return true;
}
return true;
} break;
case eAddressTypeHost:
break;
case eAddressTypeInvalid:
case eAddressTypeFile:
break;
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
}
Fix libstdc++ data formatters on Ubuntu 15.10 x86_64 See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
2015-10-22 00:23:38 +00:00
return false;
}
Revert "Improve the libstdc++ smart pointer formatters" This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
2016-10-25 13:24:53 +00:00
LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(
lldb::ValueObjectSP valobj_sp)
: SyntheticChildrenFrontEnd(*valobj_sp) {
if (valobj_sp)
Update();
}
size_t LibStdcppSharedPtrSyntheticFrontEnd::CalculateNumChildren() { return 1; }
lldb::ValueObjectSP
LibStdcppSharedPtrSyntheticFrontEnd::GetChildAtIndex(size_t idx) {
ValueObjectSP valobj_sp = m_backend.GetSP();
if (!valobj_sp)
return lldb::ValueObjectSP();
if (idx == 0)
return valobj_sp->GetChildMemberWithName(ConstString("_M_ptr"), true);
else
return lldb::ValueObjectSP();
}
bool LibStdcppSharedPtrSyntheticFrontEnd::Update() { return false; }
bool LibStdcppSharedPtrSyntheticFrontEnd::MightHaveChildren() { return true; }
size_t LibStdcppSharedPtrSyntheticFrontEnd::GetIndexOfChildWithName(
Pass ConstString by value (NFC) My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-03-06 21:22:25 +00:00
ConstString name) {
Allow direct comparison of ConstString against StringRef Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
2019-04-26 07:21:36 +00:00
if (name == "_M_ptr")
Revert "Improve the libstdc++ smart pointer formatters" This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
2016-10-25 13:24:53 +00:00
return 0;
return UINT32_MAX;
}
SyntheticChildrenFrontEnd *
lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(
CXXSyntheticChildren *, lldb::ValueObjectSP valobj_sp) {
return (valobj_sp ? new LibStdcppSharedPtrSyntheticFrontEnd(valobj_sp)
: nullptr);
}
bool lldb_private::formatters::LibStdcppSmartPointerSummaryProvider(
ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
ValueObjectSP valobj_sp(valobj.GetNonSyntheticValue());
if (!valobj_sp)
return false;
ValueObjectSP ptr_sp(
valobj_sp->GetChildMemberWithName(ConstString("_M_ptr"), true));
if (!ptr_sp)
return false;
ValueObjectSP usecount_sp(valobj_sp->GetChildAtNamePath(
{ConstString("_M_refcount"), ConstString("_M_pi"),
ConstString("_M_use_count")}));
if (!usecount_sp)
return false;
if (ptr_sp->GetValueAsUnsigned(0) == 0 ||
usecount_sp->GetValueAsUnsigned(0) == 0) {
stream.Printf("nullptr");
return true;
}
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Status error;
Revert "Improve the libstdc++ smart pointer formatters" This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
2016-10-25 13:24:53 +00:00
ValueObjectSP pointee_sp = ptr_sp->Dereference(error);
if (pointee_sp && error.Success()) {
if (pointee_sp->DumpPrintableRepresentation(
stream, ValueObject::eValueObjectRepresentationStyleSummary,
lldb::eFormatInvalid,
Simplify the PrintableRepresentationSpecialCases code; we never used the ePrintableRepresentationSpecialCasesOnly value and with enum classes the names doesn't need to be that long llvm-svn: 286176
2016-11-07 23:32:20 +00:00
ValueObject::PrintableRepresentationSpecialCases::eDisable,
false)) {
Revert "Improve the libstdc++ smart pointer formatters" This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
2016-10-25 13:24:53 +00:00
return true;
}
}
stream.Printf("ptr = 0x%" PRIx64, ptr_sp->GetValueAsUnsigned(0));
return true;
}
Reference in New Issue Copy Permalink