maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/DataFormatters/FormattersHelpers.cpp

153 lines
5.2 KiB
C++
Raw Normal View History

*** 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-07 04:57:50 +08:00
//===-- FormattersHelpers.cpp -------------------------------------*- C++
//-*-===//
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/DataFormatters/FormattersHelpers.h"
#include "lldb/Core/ConstString.h"
#include "lldb/Core/RegularExpression.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 08:33:51 +08:00
#include "lldb/Target/StackFrame.h"
Rationalization of includes in the data formatters code llvm-svn: 250798
2015-10-20 12:50:09 +08:00
#include "lldb/Target/Target.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 08:33:51 +08:00
#include "lldb/Target/Thread.h"
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::formatters;
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddFormat(
TypeCategoryImpl::SharedPointer category_sp, lldb::Format format,
ConstString type_name, TypeFormatImpl::Flags flags, bool regex) {
lldb::TypeFormatImplSP format_sp(new TypeFormatImpl_Format(format, flags));
if (regex)
category_sp->GetRegexTypeFormatsContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
format_sp);
else
category_sp->GetTypeFormatsContainer()->Add(type_name, format_sp);
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
}
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddSummary(
TypeCategoryImpl::SharedPointer category_sp, TypeSummaryImplSP summary_sp,
ConstString type_name, bool regex) {
if (regex)
category_sp->GetRegexTypeSummariesContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
summary_sp);
else
category_sp->GetTypeSummariesContainer()->Add(type_name, summary_sp);
Add the ability for formatter categories to be bound to one or more languages What that does is it restricts formatters in those categories to only match to types coming from "compatible" source languages llvm-svn: 247872
2015-09-17 08:14:50 +08:00
}
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddStringSummary(
TypeCategoryImpl::SharedPointer category_sp, const char *string,
ConstString type_name, TypeSummaryImpl::Flags flags, bool regex) {
lldb::TypeSummaryImplSP summary_sp(new StringSummaryFormat(flags, string));
if (regex)
category_sp->GetRegexTypeSummariesContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
summary_sp);
else
category_sp->GetTypeSummariesContainer()->Add(type_name, summary_sp);
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
}
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddOneLineSummary(
TypeCategoryImpl::SharedPointer category_sp, ConstString type_name,
TypeSummaryImpl::Flags flags, bool regex) {
flags.SetShowMembersOneLiner(true);
lldb::TypeSummaryImplSP summary_sp(new StringSummaryFormat(flags, ""));
if (regex)
category_sp->GetRegexTypeSummariesContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
summary_sp);
else
category_sp->GetTypeSummariesContainer()->Add(type_name, summary_sp);
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
}
#ifndef LLDB_DISABLE_PYTHON
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddCXXSummary(
TypeCategoryImpl::SharedPointer category_sp,
CXXFunctionSummaryFormat::Callback funct, const char *description,
ConstString type_name, TypeSummaryImpl::Flags flags, bool regex) {
lldb::TypeSummaryImplSP summary_sp(
new CXXFunctionSummaryFormat(flags, funct, description));
if (regex)
category_sp->GetRegexTypeSummariesContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
summary_sp);
else
category_sp->GetTypeSummariesContainer()->Add(type_name, summary_sp);
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
}
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddCXXSynthetic(
TypeCategoryImpl::SharedPointer category_sp,
CXXSyntheticChildren::CreateFrontEndCallback generator,
const char *description, ConstString type_name,
ScriptedSyntheticChildren::Flags flags, bool regex) {
lldb::SyntheticChildrenSP synth_sp(
new CXXSyntheticChildren(flags, description, generator));
if (regex)
category_sp->GetRegexTypeSyntheticsContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
synth_sp);
else
category_sp->GetTypeSyntheticsContainer()->Add(type_name, synth_sp);
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
}
*** 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-07 04:57:50 +08:00
void lldb_private::formatters::AddFilter(
TypeCategoryImpl::SharedPointer category_sp,
std::vector<std::string> children, const char *description,
ConstString type_name, ScriptedSyntheticChildren::Flags flags, bool regex) {
TypeFilterImplSP filter_sp(new TypeFilterImpl(flags));
for (auto child : children)
filter_sp->AddExpressionPath(child);
if (regex)
category_sp->GetRegexTypeFiltersContainer()->Add(
RegularExpressionSP(new RegularExpression(type_name.AsCString())),
filter_sp);
else
category_sp->GetTypeFiltersContainer()->Add(type_name, filter_sp);
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
}
#endif
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 08:33:51 +08:00
*** 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-07 04:57:50 +08:00
size_t lldb_private::formatters::ExtractIndexFromString(const char *item_name) {
if (!item_name || !*item_name)
return UINT32_MAX;
if (*item_name != '[')
return UINT32_MAX;
item_name++;
char *endptr = NULL;
unsigned long int idx = ::strtoul(item_name, &endptr, 0);
if (idx == 0 && endptr == item_name)
return UINT32_MAX;
if (idx == ULONG_MAX)
return UINT32_MAX;
return idx;
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 08:33:51 +08:00
}
Fix evaluation of unicode character arrays (char16_t[] and char32_t[]) Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
2015-09-25 10:16:52 +08:00
lldb::addr_t
*** 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-07 04:57:50 +08:00
lldb_private::formatters::GetArrayAddressOrPointerValue(ValueObject &valobj) {
lldb::addr_t data_addr = LLDB_INVALID_ADDRESS;
Fix evaluation of unicode character arrays (char16_t[] and char32_t[]) Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
2015-09-25 10:16:52 +08:00
*** 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-07 04:57:50 +08:00
if (valobj.IsPointerType())
data_addr = valobj.GetValueAsUnsigned(0);
else if (valobj.IsArrayType())
data_addr = valobj.GetAddressOf();
Fix evaluation of unicode character arrays (char16_t[] and char32_t[]) Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
2015-09-25 10:16:52 +08:00
*** 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-07 04:57:50 +08:00
return data_addr;
Fix evaluation of unicode character arrays (char16_t[] and char32_t[]) Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
2015-09-25 10:16:52 +08:00
}