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

1188 lines
54 KiB
C++
Raw Normal View History

Committing type format code for Enrico Granata. This commit adds a new top level command named "type". Currently this command implements three commands: type format add <format> <typename1> [<typename2> ...] type format delete <typename1> [<typename2> ...] type format list [<typename1> [<typename2>] ...] This allows you to specify the default format that will be used to display types when you use "frame variable" or "expression", or the SBValue classes. Examples: // Format uint*_t as hex type format add x uint16_t uint32_t uint64_t // Format intptr_t as a pointer type format add p intptr_t The format characters are the same as "printf" for the most part with many additions. These format character specifiers are also used in many other commands ("frame variable" for one). The current list of format characters include: a - char buffer b - binary B - boolean c - char C - printable char d - signed decimal e - float f - float g - float i - signed decimal I - complex integer o - octal O - OSType p - pointer s - c-string u - unsigned decimal x - hex X - complex float y - bytes Y - bytes with ASCII llvm-svn: 133728
2011-06-24 01:59:56 +08:00
//===-- FormatManager.cpp -------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Core/FormatManager.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements llvm-svn: 135238
2011-07-15 10:26:42 +08:00
#include "lldb/Core/Debugger.h"
Committing type format code for Enrico Granata. This commit adds a new top level command named "type". Currently this command implements three commands: type format add <format> <typename1> [<typename2> ...] type format delete <typename1> [<typename2> ...] type format list [<typename1> [<typename2>] ...] This allows you to specify the default format that will be used to display types when you use "frame variable" or "expression", or the SBValue classes. Examples: // Format uint*_t as hex type format add x uint16_t uint32_t uint64_t // Format intptr_t as a pointer type format add p intptr_t The format characters are the same as "printf" for the most part with many additions. These format character specifiers are also used in many other commands ("frame variable" for one). The current list of format characters include: a - char buffer b - binary B - boolean c - char C - printable char d - signed decimal e - float f - float g - float i - signed decimal I - complex integer o - octal O - OSType p - pointer s - c-string u - unsigned decimal x - hex X - complex float y - bytes Y - bytes with ASCII llvm-svn: 133728
2011-06-24 01:59:56 +08:00
using namespace lldb;
using namespace lldb_private;
Centralized all of the format to c-string and to format character code inside the FormatManager class. Modified the format arguments in any commands to be able to use a single character format, or a full format name, or a partial format name if no full format names match. Modified any code that was displaying formats to use the new FormatManager calls so that our help text and errors never get out of date. Modified the display of the "type format list" command to be a bit more human readable by showing the format as a format string rather than the single character format char. llvm-svn: 133765
2011-06-24 05:22:24 +08:00
struct FormatInfo
{
Format format;
const char format_char; // One or more format characters that can be used for this format.
const char *format_name; // Long format name that can be used to specify the current format
};
static FormatInfo
g_format_infos[] =
{
{ eFormatDefault , '\0' , "default" },
{ eFormatBoolean , 'B' , "boolean" },
{ eFormatBinary , 'b' , "binary" },
{ eFormatBytes , 'y' , "bytes" },
{ eFormatBytesWithASCII , 'Y' , "bytes with ASCII" },
{ eFormatChar , 'c' , "character" },
{ eFormatCharPrintable , 'C' , "printable character" },
{ eFormatComplexFloat , 'F' , "complex float" },
{ eFormatCString , 's' , "c-string" },
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. llvm-svn: 143114
2011-10-28 01:55:14 +08:00
{ eFormatDecimal , 'd' , "decimal" },
Centralized all of the format to c-string and to format character code inside the FormatManager class. Modified the format arguments in any commands to be able to use a single character format, or a full format name, or a partial format name if no full format names match. Modified any code that was displaying formats to use the new FormatManager calls so that our help text and errors never get out of date. Modified the display of the "type format list" command to be a bit more human readable by showing the format as a format string rather than the single character format char. llvm-svn: 133765
2011-06-24 05:22:24 +08:00
{ eFormatEnum , 'E' , "enumeration" },
{ eFormatHex , 'x' , "hex" },
<rdar://problem/10449092> Adding a new uppercase hex format specifier. This commit also changes the short names for formats so that uppercase hex can be 'X', which was previously assigned to hex float. hex float now has no short name. llvm-svn: 161606
2012-08-10 03:33:34 +08:00
{ eFormatHexUppercase , 'X' , "uppercase hex" },
Centralized all of the format to c-string and to format character code inside the FormatManager class. Modified the format arguments in any commands to be able to use a single character format, or a full format name, or a partial format name if no full format names match. Modified any code that was displaying formats to use the new FormatManager calls so that our help text and errors never get out of date. Modified the display of the "type format list" command to be a bit more human readable by showing the format as a format string rather than the single character format char. llvm-svn: 133765
2011-06-24 05:22:24 +08:00
{ eFormatFloat , 'f' , "float" },
{ eFormatOctal , 'o' , "octal" },
{ eFormatOSType , 'O' , "OSType" },
{ eFormatUnicode16 , 'U' , "unicode16" },
{ eFormatUnicode32 , '\0' , "unicode32" },
{ eFormatUnsigned , 'u' , "unsigned decimal" },
{ eFormatPointer , 'p' , "pointer" },
{ eFormatVectorOfChar , '\0' , "char[]" },
{ eFormatVectorOfSInt8 , '\0' , "int8_t[]" },
{ eFormatVectorOfUInt8 , '\0' , "uint8_t[]" },
{ eFormatVectorOfSInt16 , '\0' , "int16_t[]" },
{ eFormatVectorOfUInt16 , '\0' , "uint16_t[]" },
Fixed some format names llvm-svn: 134492
2011-07-06 23:56:06 +08:00
{ eFormatVectorOfSInt32 , '\0' , "int32_t[]" },
{ eFormatVectorOfUInt32 , '\0' , "uint32_t[]" },
{ eFormatVectorOfSInt64 , '\0' , "int64_t[]" },
{ eFormatVectorOfUInt64 , '\0' , "uint64_t[]" },
Centralized all of the format to c-string and to format character code inside the FormatManager class. Modified the format arguments in any commands to be able to use a single character format, or a full format name, or a partial format name if no full format names match. Modified any code that was displaying formats to use the new FormatManager calls so that our help text and errors never get out of date. Modified the display of the "type format list" command to be a bit more human readable by showing the format as a format string rather than the single character format char. llvm-svn: 133765
2011-06-24 05:22:24 +08:00
{ eFormatVectorOfFloat32, '\0' , "float32[]" },
{ eFormatVectorOfFloat64, '\0' , "float64[]" },
{ eFormatVectorOfUInt128, '\0' , "uint128_t[]" },
{ eFormatComplexInteger , 'I' , "complex integer" },
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. llvm-svn: 143114
2011-10-28 01:55:14 +08:00
{ eFormatCharArray , 'a' , "character array" },
{ eFormatAddressInfo , 'A' , "address" },
<rdar://problem/10449092> Adding a new uppercase hex format specifier. This commit also changes the short names for formats so that uppercase hex can be 'X', which was previously assigned to hex float. hex float now has no short name. llvm-svn: 161606
2012-08-10 03:33:34 +08:00
{ eFormatHexFloat , '\0' , "hex float" },
Added a 'void' format so that the user can manually suppress all non-error output from the "expression" command. <rdar://problem/11225150> llvm-svn: 161502
2012-08-09 01:35:10 +08:00
{ eFormatInstruction , 'i' , "instruction" },
{ eFormatVoid , 'v' , "void" }
Centralized all of the format to c-string and to format character code inside the FormatManager class. Modified the format arguments in any commands to be able to use a single character format, or a full format name, or a partial format name if no full format names match. Modified any code that was displaying formats to use the new FormatManager calls so that our help text and errors never get out of date. Modified the display of the "type format list" command to be a bit more human readable by showing the format as a format string rather than the single character format char. llvm-svn: 133765
2011-06-24 05:22:24 +08:00
};
static uint32_t
g_num_format_infos = sizeof(g_format_infos)/sizeof(FormatInfo);
static bool
GetFormatFromFormatChar (char format_char, Format &format)
{
for (uint32_t i=0; i<g_num_format_infos; ++i)
{
if (g_format_infos[i].format_char == format_char)
{
format = g_format_infos[i].format;
return true;
}
}
format = eFormatInvalid;
return false;
}
static bool
GetFormatFromFormatName (const char *format_name, bool partial_match_ok, Format &format)
{
uint32_t i;
for (i=0; i<g_num_format_infos; ++i)
{
if (strcasecmp (g_format_infos[i].format_name, format_name) == 0)
{
format = g_format_infos[i].format;
return true;
}
}
if (partial_match_ok)
{
for (i=0; i<g_num_format_infos; ++i)
{
if (strcasestr (g_format_infos[i].format_name, format_name) == g_format_infos[i].format_name)
{
format = g_format_infos[i].format;
return true;
}
}
}
format = eFormatInvalid;
return false;
}
bool
FormatManager::GetFormatFromCString (const char *format_cstr,
bool partial_match_ok,
lldb::Format &format)
{
bool success = false;
if (format_cstr && format_cstr[0])
{
if (format_cstr[1] == '\0')
{
success = GetFormatFromFormatChar (format_cstr[0], format);
if (success)
return true;
}
success = GetFormatFromFormatName (format_cstr, partial_match_ok, format);
}
if (!success)
format = eFormatInvalid;
return success;
}
char
FormatManager::GetFormatAsFormatChar (lldb::Format format)
{
for (uint32_t i=0; i<g_num_format_infos; ++i)
{
if (g_format_infos[i].format == format)
return g_format_infos[i].format_char;
}
return '\0';
}
const char *
FormatManager::GetFormatAsCString (Format format)
{
if (format >= eFormatDefault && format < kNumFormats)
return g_format_infos[format].format_name;
return NULL;
}
several improvements to "type summary": - type names can now be regular expressions (exact matching is done first, and is faster) - integral (and floating) types can be printed as bitfields, i.e. ${var[low-high]} will extract bits low thru high of the value and print them - array subscripts are supported, both for arrays and for pointers. the syntax is ${*var[low-high]}, or ${*var[]} to print the whole array (the latter only works for statically sized arrays) - summary is now printed by default when a summary string references a variable. if that variable's type has no summary, value is printed instead. to force value, you can use %V as a format specifier - basic support for ObjectiveC: - ObjectiveC inheritance chains are now walked through - %@ can be specified as a summary format, to print the ObjectiveC runtime description for an object - some bug fixes llvm-svn: 134293
2011-07-02 08:25:22 +08:00
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::TypeCategoryImpl(IFormatChangeListener* clist,
ConstString name) :
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
m_summary_nav(new SummaryNavigator("summary",clist)),
m_regex_summary_nav(new RegexSummaryNavigator("regex-summary",clist)),
m_filter_nav(new FilterNavigator("filter",clist)),
m_regex_filter_nav(new RegexFilterNavigator("regex-filter",clist)),
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
m_synth_nav(new SynthNavigator("synth",clist)),
m_regex_synth_nav(new RegexSynthNavigator("regex-synth",clist)),
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
m_enabled(false),
m_change_listener(clist),
m_mutex(Mutex::eMutexTypeRecursive),
m_name(name)
{}
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
bool
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::Get (ValueObject& valobj,
lldb::TypeSummaryImplSP& entry,
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
lldb::DynamicValueType use_dynamic,
uint32_t* reason)
{
if (!IsEnabled())
return false;
if (GetSummaryNavigator()->Get(valobj, entry, use_dynamic, reason))
return true;
bool regex = GetRegexSummaryNavigator()->Get(valobj, entry, use_dynamic, reason);
if (regex && reason)
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. llvm-svn: 143114
2011-10-28 01:55:14 +08:00
*reason |= lldb_private::eFormatterChoiceCriterionRegularExpressionSummary;
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
return regex;
}
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
bool
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::Get(ValueObject& valobj,
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
lldb::SyntheticChildrenSP& entry_sp,
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
lldb::DynamicValueType use_dynamic,
uint32_t* reason)
{
if (!IsEnabled())
return false;
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeFilterImpl::SharedPointer filter_sp;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
uint32_t reason_filter = 0;
bool regex_filter = false;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
// first find both Filter and Synth, and then check which is most recent
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
if (!GetFilterNavigator()->Get(valobj, filter_sp, use_dynamic, &reason_filter))
regex_filter = GetRegexFilterNavigator()->Get (valobj, filter_sp, use_dynamic, &reason_filter);
#ifndef LLDB_DISABLE_PYTHON
bool regex_synth = false;
uint32_t reason_synth = 0;
bool pick_synth = false;
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeSyntheticImpl::SharedPointer synth;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (!GetSyntheticNavigator()->Get(valobj, synth, use_dynamic, &reason_synth))
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
regex_synth = GetRegexSyntheticNavigator()->Get (valobj, synth, use_dynamic, &reason_synth);
if (!filter_sp.get() && !synth.get())
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return false;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
else if (!filter_sp.get() && synth.get())
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
pick_synth = true;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
else if (filter_sp.get() && !synth.get())
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
pick_synth = false;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
else /*if (filter_sp.get() && synth.get())*/
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
if (filter_sp->GetRevision() > synth->GetRevision())
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
pick_synth = false;
else
pick_synth = true;
}
if (pick_synth)
{
if (regex_synth && reason)
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. llvm-svn: 143114
2011-10-28 01:55:14 +08:00
*reason |= lldb_private::eFormatterChoiceCriterionRegularExpressionFilter;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
entry_sp = synth;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
else
{
if (regex_filter && reason)
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. llvm-svn: 143114
2011-10-28 01:55:14 +08:00
*reason |= lldb_private::eFormatterChoiceCriterionRegularExpressionFilter;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
entry_sp = filter_sp;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#else
if (filter_sp)
{
entry_sp = filter_sp;
return true;
}
#endif
return false;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
}
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
void
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::Clear (FormatCategoryItems items)
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
{
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSummary) == eFormatCategoryItemSummary )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
m_summary_nav->Clear();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSummary) == eFormatCategoryItemRegexSummary )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
m_regex_summary_nav->Clear();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemFilter) == eFormatCategoryItemFilter )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
m_filter_nav->Clear();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexFilter) == eFormatCategoryItemRegexFilter )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
m_regex_filter_nav->Clear();
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSynth) == eFormatCategoryItemSynth )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
m_synth_nav->Clear();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSynth) == eFormatCategoryItemRegexSynth )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
m_regex_synth_nav->Clear();
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
}
bool
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::Delete (ConstString name,
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
FormatCategoryItems items)
{
bool success = false;
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSummary) == eFormatCategoryItemSummary )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
success = m_summary_nav->Delete(name) || success;
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSummary) == eFormatCategoryItemRegexSummary )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
success = m_regex_summary_nav->Delete(name) || success;
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemFilter) == eFormatCategoryItemFilter )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
success = m_filter_nav->Delete(name) || success;
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexFilter) == eFormatCategoryItemRegexFilter )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
success = m_regex_filter_nav->Delete(name) || success;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSynth) == eFormatCategoryItemSynth )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
success = m_synth_nav->Delete(name) || success;
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSynth) == eFormatCategoryItemRegexSynth )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
success = m_regex_synth_nav->Delete(name) || success;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
return success;
}
uint32_t
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::GetCount (FormatCategoryItems items)
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
{
uint32_t count = 0;
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSummary) == eFormatCategoryItemSummary )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
count += m_summary_nav->GetCount();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSummary) == eFormatCategoryItemRegexSummary )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
count += m_regex_summary_nav->GetCount();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemFilter) == eFormatCategoryItemFilter )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
count += m_filter_nav->GetCount();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexFilter) == eFormatCategoryItemRegexFilter )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
count += m_regex_filter_nav->GetCount();
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSynth) == eFormatCategoryItemSynth )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
count += m_synth_nav->GetCount();
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSynth) == eFormatCategoryItemRegexSynth )
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
count += m_regex_synth_nav->GetCount();
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files llvm-svn: 138279
2011-08-23 06:03:47 +08:00
return count;
}
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
bool
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::AnyMatches(ConstString type_name,
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
FormatCategoryItems items,
bool only_enabled,
const char** matching_category,
FormatCategoryItems* matching_type)
{
if (!IsEnabled() && only_enabled)
return false;
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
lldb::TypeSummaryImplSP summary;
TypeFilterImpl::SharedPointer filter;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeSyntheticImpl::SharedPointer synth;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSummary) == eFormatCategoryItemSummary )
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
if (m_summary_nav->Get(type_name, summary))
{
if (matching_category)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
*matching_category = m_name.GetCString();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (matching_type)
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
*matching_type = eFormatCategoryItemSummary;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
}
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSummary) == eFormatCategoryItemRegexSummary )
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
if (m_regex_summary_nav->Get(type_name, summary))
{
if (matching_category)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
*matching_category = m_name.GetCString();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (matching_type)
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
*matching_type = eFormatCategoryItemRegexSummary;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
}
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemFilter) == eFormatCategoryItemFilter )
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
if (m_filter_nav->Get(type_name, filter))
{
if (matching_category)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
*matching_category = m_name.GetCString();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (matching_type)
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
*matching_type = eFormatCategoryItemFilter;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
}
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexFilter) == eFormatCategoryItemRegexFilter )
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
if (m_regex_filter_nav->Get(type_name, filter))
{
if (matching_category)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
*matching_category = m_name.GetCString();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (matching_type)
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
*matching_type = eFormatCategoryItemRegexFilter;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemSynth) == eFormatCategoryItemSynth )
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
if (m_synth_nav->Get(type_name, synth))
{
if (matching_category)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
*matching_category = m_name.GetCString();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (matching_type)
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
*matching_type = eFormatCategoryItemSynth;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
}
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
if ( (items & eFormatCategoryItemRegexSynth) == eFormatCategoryItemRegexSynth )
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
if (m_regex_synth_nav->Get(type_name, synth))
{
if (matching_category)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
*matching_category = m_name.GetCString();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
if (matching_type)
Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups llvm-svn: 138307
2011-08-23 07:45:15 +08:00
*matching_type = eFormatCategoryItemRegexSynth;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return true;
}
}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
return false;
}
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
bool
CategoryMap::AnyMatches (ConstString type_name,
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::FormatCategoryItems items,
bool only_enabled,
const char** matching_category,
TypeCategoryImpl::FormatCategoryItems* matching_type)
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
{
Mutex::Locker(m_map_mutex);
MapIterator pos, end = m_map.end();
for (pos = m_map.begin(); pos != end; pos++)
{
if (pos->second->AnyMatches(type_name,
items,
only_enabled,
matching_category,
matching_type))
return true;
}
return false;
}
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
lldb::TypeSummaryImplSP
Refactoring of Get() methods in FormatManager/FormatCategory to have explicative names and return shared-pointers instead of bools Reduced the amount of memory required to avoid loops in DumpPrintableRepresentation() from 32 bits down to 1 bit - Additionally, disallowed creating summary strings of the form ${var%S} which did nothing but cause endless loops by definition llvm-svn: 139201
2011-09-07 06:59:55 +08:00
CategoryMap::GetSummaryFormat (ValueObject& valobj,
lldb::DynamicValueType use_dynamic)
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
{
Mutex::Locker(m_map_mutex);
uint32_t reason_why;
ActiveCategoriesIterator begin, end = m_active_categories.end();
for (begin = m_active_categories.begin(); begin != end; begin++)
{
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
lldb::TypeCategoryImplSP category = *begin;
lldb::TypeSummaryImplSP current_format;
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
if (!category->Get(valobj, current_format, use_dynamic, &reason_why))
continue;
Refactoring of Get() methods in FormatManager/FormatCategory to have explicative names and return shared-pointers instead of bools Reduced the amount of memory required to avoid loops in DumpPrintableRepresentation() from 32 bits down to 1 bit - Additionally, disallowed creating summary strings of the form ${var%S} which did nothing but cause endless loops by definition llvm-svn: 139201
2011-09-07 06:59:55 +08:00
return current_format;
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
}
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
return lldb::TypeSummaryImplSP();
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
}
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
lldb::TypeSummaryImplSP
FormatManager::GetSummaryForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
return lldb::TypeSummaryImplSP();
lldb::TypeSummaryImplSP summary_chosen_sp;
uint32_t num_categories = m_categories_map.GetCount();
lldb::TypeCategoryImplSP category_sp;
uint32_t prio_category = UINT32_MAX;
for (uint32_t category_id = 0;
category_id < num_categories;
category_id++)
{
category_sp = GetCategoryAtIndex(category_id);
if (category_sp->IsEnabled() == false)
continue;
lldb::TypeSummaryImplSP summary_current_sp = category_sp->GetSummaryForType(type_sp);
if (summary_current_sp && (summary_chosen_sp.get() == NULL || (prio_category > category_sp->GetEnabledPosition())))
{
prio_category = category_sp->GetEnabledPosition();
summary_chosen_sp = summary_current_sp;
}
}
return summary_chosen_sp;
}
lldb::TypeFilterImplSP
FormatManager::GetFilterForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
return lldb::TypeFilterImplSP();
lldb::TypeFilterImplSP filter_chosen_sp;
uint32_t num_categories = m_categories_map.GetCount();
lldb::TypeCategoryImplSP category_sp;
uint32_t prio_category = UINT32_MAX;
for (uint32_t category_id = 0;
category_id < num_categories;
category_id++)
{
category_sp = GetCategoryAtIndex(category_id);
if (category_sp->IsEnabled() == false)
continue;
lldb::TypeFilterImplSP filter_current_sp((TypeFilterImpl*)category_sp->GetFilterForType(type_sp).get());
if (filter_current_sp && (filter_chosen_sp.get() == NULL || (prio_category > category_sp->GetEnabledPosition())))
{
prio_category = category_sp->GetEnabledPosition();
filter_chosen_sp = filter_current_sp;
}
}
return filter_chosen_sp;
}
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#ifndef LLDB_DISABLE_PYTHON
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
lldb::TypeSyntheticImplSP
FormatManager::GetSyntheticForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
return lldb::TypeSyntheticImplSP();
lldb::TypeSyntheticImplSP synth_chosen_sp;
uint32_t num_categories = m_categories_map.GetCount();
lldb::TypeCategoryImplSP category_sp;
uint32_t prio_category = UINT32_MAX;
for (uint32_t category_id = 0;
category_id < num_categories;
category_id++)
{
category_sp = GetCategoryAtIndex(category_id);
if (category_sp->IsEnabled() == false)
continue;
lldb::TypeSyntheticImplSP synth_current_sp((TypeSyntheticImpl*)category_sp->GetSyntheticForType(type_sp).get());
if (synth_current_sp && (synth_chosen_sp.get() == NULL || (prio_category > category_sp->GetEnabledPosition())))
{
prio_category = category_sp->GetEnabledPosition();
synth_chosen_sp = synth_current_sp;
}
}
return synth_chosen_sp;
}
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#endif
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#ifndef LLDB_DISABLE_PYTHON
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
lldb::SyntheticChildrenSP
FormatManager::GetSyntheticChildrenForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
return lldb::SyntheticChildrenSP();
lldb::TypeFilterImplSP filter_sp = GetFilterForType(type_sp);
lldb::TypeSyntheticImplSP synth_sp = GetSyntheticForType(type_sp);
if (filter_sp->GetRevision() > synth_sp->GetRevision())
return lldb::SyntheticChildrenSP(filter_sp.get());
else
return lldb::SyntheticChildrenSP(synth_sp.get());
}
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#endif
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#ifndef LLDB_DISABLE_PYTHON
Refactoring of Get() methods in FormatManager/FormatCategory to have explicative names and return shared-pointers instead of bools Reduced the amount of memory required to avoid loops in DumpPrintableRepresentation() from 32 bits down to 1 bit - Additionally, disallowed creating summary strings of the form ${var%S} which did nothing but cause endless loops by definition llvm-svn: 139201
2011-09-07 06:59:55 +08:00
lldb::SyntheticChildrenSP
CategoryMap::GetSyntheticChildren (ValueObject& valobj,
lldb::DynamicValueType use_dynamic)
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
{
Mutex::Locker(m_map_mutex);
uint32_t reason_why;
ActiveCategoriesIterator begin, end = m_active_categories.end();
for (begin = m_active_categories.begin(); begin != end; begin++)
{
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
lldb::TypeCategoryImplSP category = *begin;
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
lldb::SyntheticChildrenSP current_format;
if (!category->Get(valobj, current_format, use_dynamic, &reason_why))
continue;
Refactoring of Get() methods in FormatManager/FormatCategory to have explicative names and return shared-pointers instead of bools Reduced the amount of memory required to avoid loops in DumpPrintableRepresentation() from 32 bits down to 1 bit - Additionally, disallowed creating summary strings of the form ${var%S} which did nothing but cause endless loops by definition llvm-svn: 139201
2011-09-07 06:59:55 +08:00
return current_format;
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
}
Refactoring of Get() methods in FormatManager/FormatCategory to have explicative names and return shared-pointers instead of bools Reduced the amount of memory required to avoid loops in DumpPrintableRepresentation() from 32 bits down to 1 bit - Additionally, disallowed creating summary strings of the form ${var%S} which did nothing but cause endless loops by definition llvm-svn: 139201
2011-09-07 06:59:55 +08:00
return lldb::SyntheticChildrenSP();
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
}
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#endif
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
void
CategoryMap::LoopThrough(CallbackType callback, void* param)
{
if (callback)
{
Mutex::Locker(m_map_mutex);
// loop through enabled categories in respective order
{
ActiveCategoriesIterator begin, end = m_active_categories.end();
for (begin = m_active_categories.begin(); begin != end; begin++)
{
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
lldb::TypeCategoryImplSP category = *begin;
ConstString type = ConstString(category->GetName());
Code cleanup and refactoring (round 4): - FormatCategories now are directly mapped by ConstString objects instead of going through const char* -> ConstString -> const char* - FormatCategory callback does not pass category name anymore. This is not necessary because FormatCategory objects themselves hold their name as a member variable llvm-svn: 138254
2011-08-23 02:36:52 +08:00
if (!callback(param, category))
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
break;
}
}
// loop through disabled categories in just any order
{
MapIterator pos, end = m_map.end();
for (pos = m_map.begin(); pos != end; pos++)
{
if (pos->second->IsEnabled())
continue;
KeyType type = pos->first;
Code cleanup and refactoring (round 4): - FormatCategories now are directly mapped by ConstString objects instead of going through const char* -> ConstString -> const char* - FormatCategory callback does not pass category name anymore. This is not necessary because FormatCategory objects themselves hold their name as a member variable llvm-svn: 138254
2011-08-23 02:36:52 +08:00
if (!callback(param, pos->second))
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
break;
}
}
}
}
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImplSP
CategoryMap::GetAtIndex (uint32_t index)
{
Mutex::Locker(m_map_mutex);
if (index < m_map.size())
{
MapIterator pos, end = m_map.end();
for (pos = m_map.begin(); pos != end; pos++)
{
if (index == 0)
return pos->second;
index--;
}
}
return TypeCategoryImplSP();
}
lldb::TypeCategoryImplSP
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
FormatManager::GetCategory (const ConstString& category_name,
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
bool can_create)
{
if (!category_name)
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
return GetCategory(m_default_category_name);
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
lldb::TypeCategoryImplSP category;
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
if (m_categories_map.Get(category_name, category))
return category;
if (!can_create)
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
return lldb::TypeCategoryImplSP();
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
m_categories_map.Add(category_name,lldb::TypeCategoryImplSP(new TypeCategoryImpl(this, category_name)));
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
return GetCategory(category_name);
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
}
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
lldb::Format
FormatManager::GetSingleItemFormat(lldb::Format vector_format)
{
switch(vector_format)
{
case eFormatVectorOfChar:
return eFormatCharArray;
case eFormatVectorOfSInt8:
case eFormatVectorOfSInt16:
case eFormatVectorOfSInt32:
case eFormatVectorOfSInt64:
return eFormatDecimal;
case eFormatVectorOfUInt8:
case eFormatVectorOfUInt16:
case eFormatVectorOfUInt32:
case eFormatVectorOfUInt64:
case eFormatVectorOfUInt128:
return eFormatHex;
case eFormatVectorOfFloat32:
case eFormatVectorOfFloat64:
return eFormatFloat;
default:
return lldb::eFormatInvalid;
}
While tracking down memory consumption issue a few things were needed: the ability to dump more information about modules in "target modules list". We can now dump the shared pointer reference count for modules, the pointer to the module itself (in case performance tools can help track down who has references to said pointer), and the modification time. Added "target delete [target-idx ...]" to be able to delete targets when they are no longer needed. This will help track down memory usage issues and help to resolve when module ref counts keep getting incremented. If the command gets no arguments, the currently selected target will be deleted. If any arguments are given, they must all be valid target indexes (use the "target list" command to get the current target indexes). Took care of a bunch of "no newline at end of file" warnings. TimeValue objects can now dump their time to a lldb_private::Stream object. Modified the "target modules list --global" command to not error out if there are no targets since it doesn't require a target. Fixed an issue in the MacOSX DYLD dynamic loader plug-in where if a shared library was updated on disk, we would keep using the older one, even if it was updated. Don't allow the ModuleList::GetSharedModule(...) to return an empty module. Previously we could specify a valid path on disc to a module, and specify an architecture that wasn't contained in that module and get a shared pointer to a module that wouldn't be able to return an object file or a symbol file. We now make sure an object file can be extracted prior to adding the shared pointer to the module to get added to the shared list. llvm-svn: 137196
2011-08-10 10:10:13 +08:00
}
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
Third round of code cleanups: - reorganizing the PTS (Partial Template Specializations) in FormatManager.h - applied a patch by Filipe Cabecinhas to make LLDB compile with GCC Functional changes: - fixed an issue where command type summary add for type "struct Foo" would not match any types. currently, "struct" will be stripped off and type "Foo" will be matched. similar behavior occurs for class, enum and union specifiers. llvm-svn: 138020
2011-08-19 09:14:49 +08:00
ConstString
FormatManager::GetValidTypeName (const ConstString& type)
{
return ::GetValidTypeName_Impl(type);
}
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
FormatManager::FormatManager() :
m_value_nav("format",this),
m_named_summaries_map(this),
m_last_revision(0),
m_categories_map(this),
Code cleanup and refactoring (round 4): - FormatCategories now are directly mapped by ConstString objects instead of going through const char* -> ConstString -> const char* - FormatCategory callback does not pass category name anymore. This is not necessary because FormatCategory objects themselves hold their name as a member variable llvm-svn: 138254
2011-08-23 02:36:52 +08:00
m_default_category_name(ConstString("default")),
m_system_category_name(ConstString("system")),
This commit provides a new default summary for Objective-C boolean variables, which shows YES or NO instead of the character value. A new category named objc is added to contain this summary provider. Any future Objective-C related formatters would probably fit here llvm-svn: 149388
2012-02-01 01:01:51 +08:00
m_gnu_cpp_category_name(ConstString("gnu-libstdc++")),
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
m_libcxx_category_name(ConstString("libcxx")),
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
m_objc_category_name(ConstString("objc")),
m_corefoundation_category_name(ConstString("CoreFoundation")),
m_coregraphics_category_name(ConstString("CoreGraphics")),
m_coreservices_category_name(ConstString("CoreServices")),
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-24 07:10:03 +08:00
m_vectortypes_category_name(ConstString("VectorTypes")),
m_appkit_category_name(ConstString("AppKit"))
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
{
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
LoadSystemFormatters();
LoadSTLFormatters();
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
LoadLibcxxFormatters();
Patch Enrico's changes from r150558 on 2012-02-14 to build even if Python is not available (LLDB_DISABLE_PYTHON is defined). Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if this build is LLDB_DISABLE_PYTHON. Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj to only do this copying for Mac native builds. llvm-svn: 151035
2012-02-21 13:33:55 +08:00
#ifndef LLDB_DISABLE_PYTHON
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
LoadObjCFormatters();
Patch Enrico's changes from r150558 on 2012-02-14 to build even if Python is not available (LLDB_DISABLE_PYTHON is defined). Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if this build is LLDB_DISABLE_PYTHON. Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj to only do this copying for Mac native builds. llvm-svn: 151035
2012-02-21 13:33:55 +08:00
#endif
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
EnableCategory(m_objc_category_name,CategoryMap::Last);
Automatically enabling the Cocoa formatter categories for command-line LLDB. Previously, the categories were filled in but disabled by default. Tweaking test cases appropriately to keep working and do the right thing llvm-svn: 155605
2012-04-26 09:40:38 +08:00
EnableCategory(m_corefoundation_category_name,CategoryMap::Last);
EnableCategory(m_appkit_category_name,CategoryMap::Last);
EnableCategory(m_coreservices_category_name,CategoryMap::Last);
EnableCategory(m_coregraphics_category_name,CategoryMap::Last);
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
EnableCategory(m_gnu_cpp_category_name,CategoryMap::Last);
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
EnableCategory(m_libcxx_category_name,CategoryMap::Last);
Automatically enabling the Cocoa formatter categories for command-line LLDB. Previously, the categories were filled in but disabled by default. Tweaking test cases appropriately to keep working and do the right thing llvm-svn: 155605
2012-04-26 09:40:38 +08:00
EnableCategory(m_vectortypes_category_name,CategoryMap::Last);
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
EnableCategory(m_system_category_name,CategoryMap::Last);
}
void
FormatManager::LoadSTLFormatters()
{
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
TypeSummaryImpl::Flags stl_summary_flags;
stl_summary_flags.SetCascades(true)
.SetSkipPointers(false)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(true)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false);
lldb::TypeSummaryImplSP std_string_summary_sp(new StringSummaryFormat(stl_summary_flags,
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
"${var._M_dataplus._M_p}"));
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
TypeCategoryImpl::SharedPointer gnu_category_sp = GetCategory(m_gnu_cpp_category_name);
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
gnu_category_sp->GetSummaryNavigator()->Add(ConstString("std::string"),
std_string_summary_sp);
gnu_category_sp->GetSummaryNavigator()->Add(ConstString("std::basic_string<char>"),
std_string_summary_sp);
gnu_category_sp->GetSummaryNavigator()->Add(ConstString("std::basic_string<char,std::char_traits<char>,std::allocator<char> >"),
std_string_summary_sp);
<rdar://problem/11113279> Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
2012-03-27 07:03:23 +08:00
gnu_category_sp->GetSummaryNavigator()->Add(ConstString("std::basic_string<char, std::char_traits<char>, std::allocator<char> >"),
Added a new --omit-names (-O, uppercase letter o) option to "type summary add". When used in conjunction with --inline-children, this option will cause the names of the values to be omitted from the output. This can be beneficial in cases such as vFloat, where it will compact the representation from ([0]=1,[1]=2,[2]=3,[3]=4) to (1, 2, 3, 4). Added a test case to check that the new option works correctly. Also took some time to revisit SummaryFormat and related classes and tweak them for added readability and maintainability. Finally, added a new class name to which the std::string summary should be applied. llvm-svn: 149644
2012-02-03 07:34:52 +08:00
std_string_summary_sp);
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#ifndef LLDB_DISABLE_PYTHON
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
SyntheticChildren::Flags stl_synth_flags;
stl_synth_flags.SetCascades(true).SetSkipPointers(false).SetSkipReferences(false);
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
gnu_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::vector<.+>(( )?&)?$")),
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.cpp.gnu_libstdcpp.StdVectorSynthProvider")));
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
gnu_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::map<.+> >(( )?&)?$")),
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.cpp.gnu_libstdcpp.StdMapSynthProvider")));
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
gnu_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::list<.+>(( )?&)?$")),
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.cpp.gnu_libstdcpp.StdListSynthProvider")));
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
having std::vector still show children even if it now has a builtin summary - having the std::vector test case deal with the fact that we now have said builtin summary llvm-svn: 151870
2012-03-02 09:14:02 +08:00
stl_summary_flags.SetDontShowChildren(false);
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
gnu_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::vector<.+>(( )?&)?$")),
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags,
"size=${svar%#}")));
gnu_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::map<.+> >(( )?&)?$")),
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags,
"size=${svar%#}")));
gnu_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::list<.+>(( )?&)?$")),
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags,
"size=${svar%#}")));
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
#endif
}
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
void
FormatManager::LoadLibcxxFormatters()
{
TypeSummaryImpl::Flags stl_summary_flags;
stl_summary_flags.SetCascades(true)
.SetSkipPointers(false)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(true)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false);
Mark newly added synthesizer calls as being #ifndef LLDB_DISABLE_PYTHON llvm-svn: 152599
2012-03-13 09:19:42 +08:00
#ifndef LLDB_DISABLE_PYTHON
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 10:06:30 +08:00
std::string code(" lldb.formatters.cpp.libcxx.stdstring_SummaryProvider(valobj,internal_dict)");
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
lldb::TypeSummaryImplSP std_string_summary_sp(new ScriptSummaryFormat(stl_summary_flags, "lldb.formatters.cpp.libcxx.stdstring_SummaryProvider",code.c_str()));
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
TypeCategoryImpl::SharedPointer libcxx_category_sp = GetCategory(m_libcxx_category_name);
libcxx_category_sp->GetSummaryNavigator()->Add(ConstString("std::__1::string"),
std_string_summary_sp);
<rdar://problem/11113279> Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
2012-03-27 07:03:23 +08:00
libcxx_category_sp->GetSummaryNavigator()->Add(ConstString("std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >"),
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
std_string_summary_sp);
Mark newly added synthesizer calls as being #ifndef LLDB_DISABLE_PYTHON llvm-svn: 152599
2012-03-13 09:19:42 +08:00
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
SyntheticChildren::Flags stl_synth_flags;
stl_synth_flags.SetCascades(true).SetSkipPointers(false).SetSkipReferences(false);
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
libcxx_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::vector<.+>(( )?&)?$")),
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.cpp.libcxx.stdvector_SynthProvider")));
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
libcxx_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::list<.+>(( )?&)?$")),
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.cpp.libcxx.stdlist_SynthProvider")));
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
libcxx_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::map<.+> >(( )?&)?$")),
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.cpp.libcxx.stdmap_SynthProvider")));
Data formatters for libc++ deque and shared/weak ptrs - a contribution by Jared Grubb llvm-svn: 162680
2012-08-28 01:42:50 +08:00
libcxx_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^(std::__1::)deque<.+>(( )?&)?$")),
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
"lldb.formatters.cpp.libcxx.stddeque_SynthProvider")));
libcxx_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^(std::__1::)shared_ptr<.+>(( )?&)?$")),
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
"lldb.formatters.cpp.libcxx.stdsharedptr_SynthProvider")));
libcxx_category_sp->GetRegexSyntheticNavigator()->Add(RegularExpressionSP(new RegularExpression("^(std::__1::)weak_ptr<.+>(( )?&)?$")),
SyntheticChildrenSP(new TypeSyntheticImpl(stl_synth_flags,
"lldb.formatters.cpp.libcxx.stdsharedptr_SynthProvider")));
stl_summary_flags.SetDontShowChildren(false);stl_summary_flags.SetSkipPointers(true);
libcxx_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::vector<.+>(( )?&)?$")),
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags, "size=${svar%#}")));
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
libcxx_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::list<.+>(( )?&)?$")),
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags, "size=${svar%#}")));
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
libcxx_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::map<.+> >(( )?&)?$")),
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags, "size=${svar%#}")));
Data formatters for libc++ deque and shared/weak ptrs - a contribution by Jared Grubb llvm-svn: 162680
2012-08-28 01:42:50 +08:00
libcxx_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::deque<.+>(( )?&)?$")),
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags, "size=${svar%#}")));
libcxx_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::shared_ptr<.+>(( )?&)?$")),
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags, "{${var.__ptr_%S}} (strong=${var.count} weak=${var.weak_count})")));
libcxx_category_sp->GetRegexSummaryNavigator()->Add(RegularExpressionSP(new RegularExpression("^std::__1::weak_ptr<.+>(( )?&)?$")),
TypeSummaryImplSP(new StringSummaryFormat(stl_summary_flags, "{${var.__ptr_%S}} (strong=${var.count} weak=${var.weak_count})")));
Added formatters for libc++ (http://libcxx.llvm.org): std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
2012-03-13 03:47:17 +08:00
#endif
}
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
void
FormatManager::LoadSystemFormatters()
{
lldb::TypeSummaryImplSP string_format(new StringSummaryFormat(TypeSummaryImpl::Flags().SetCascades(false)
.SetSkipPointers(true)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(false)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false),
"${var%s}"));
lldb::TypeSummaryImplSP string_array_format(new StringSummaryFormat(TypeSummaryImpl::Flags().SetCascades(false)
.SetSkipPointers(true)
.SetSkipReferences(false)
.SetDontShowChildren(false)
.SetDontShowValue(true)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false),
"${var%s}"));
lldb::RegularExpressionSP any_size_char_arr(new RegularExpression("char \\[[0-9]+\\]"));
TypeCategoryImpl::SharedPointer sys_category_sp = GetCategory(m_system_category_name);
sys_category_sp->GetSummaryNavigator()->Add(ConstString("char *"), string_format);
sys_category_sp->GetSummaryNavigator()->Add(ConstString("const char *"), string_format);
sys_category_sp->GetRegexSummaryNavigator()->Add(any_size_char_arr, string_array_format);
<rdar://problem/11628688> Making sure to use the ostype format for OSType values llvm-svn: 160180
2012-07-14 02:54:40 +08:00
lldb::TypeSummaryImplSP ostype_summary(new StringSummaryFormat(TypeSummaryImpl::Flags().SetCascades(false)
.SetSkipPointers(true)
.SetSkipReferences(true)
.SetDontShowChildren(true)
.SetDontShowValue(false)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false),
"${var%O}"));
sys_category_sp->GetSummaryNavigator()->Add(ConstString("OSType"), ostype_summary);
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
}
static void
AddSummary(TypeCategoryImpl::SharedPointer category_sp,
const char* string,
ConstString type_name,
TypeSummaryImpl::Flags flags)
{
lldb::TypeSummaryImplSP summary_sp(new StringSummaryFormat(flags,
string));
category_sp->GetSummaryNavigator()->Add(type_name,
summary_sp);
}
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#ifndef LLDB_DISABLE_PYTHON
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-24 07:10:03 +08:00
static void
AddScriptSummary(TypeCategoryImpl::SharedPointer category_sp,
const char* funct_name,
ConstString type_name,
TypeSummaryImpl::Flags flags)
{
std::string code(" ");
<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
2012-08-08 10:06:30 +08:00
code.append(funct_name).append("(valobj,internal_dict)");
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-24 07:10:03 +08:00
lldb::TypeSummaryImplSP summary_sp(new ScriptSummaryFormat(flags,
funct_name,
code.c_str()));
category_sp->GetSummaryNavigator()->Add(type_name,
summary_sp);
}
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#endif
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-24 07:10:03 +08:00
Patch Enrico's changes from r150558 on 2012-02-14 to build even if Python is not available (LLDB_DISABLE_PYTHON is defined). Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if this build is LLDB_DISABLE_PYTHON. Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj to only do this copying for Mac native builds. llvm-svn: 151035
2012-02-21 13:33:55 +08:00
#ifndef LLDB_DISABLE_PYTHON
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
void
FormatManager::LoadObjCFormatters()
{
TypeSummaryImpl::Flags objc_flags;
objc_flags.SetCascades(false)
<rdar://problem/11773899> Formatters for BOOL* and BOOL& llvm-svn: 160181
2012-07-14 02:55:41 +08:00
.SetSkipPointers(true)
.SetSkipReferences(true)
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
.SetDontShowChildren(true)
.SetDontShowValue(true)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false);
lldb::TypeSummaryImplSP ObjC_BOOL_summary(new ScriptSummaryFormat(objc_flags,
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
"lldb.formatters.objc.objc.BOOL_SummaryProvider",
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
""));
TypeCategoryImpl::SharedPointer objc_category_sp = GetCategory(m_objc_category_name);
This commit provides a new default summary for Objective-C boolean variables, which shows YES or NO instead of the character value. A new category named objc is added to contain this summary provider. Any future Objective-C related formatters would probably fit here llvm-svn: 149388
2012-02-01 01:01:51 +08:00
objc_category_sp->GetSummaryNavigator()->Add(ConstString("BOOL"),
ObjC_BOOL_summary);
<rdar://problem/11773899> Formatters for BOOL* and BOOL& llvm-svn: 160181
2012-07-14 02:55:41 +08:00
lldb::TypeSummaryImplSP ObjC_BOOLRef_summary(new ScriptSummaryFormat(objc_flags,
"lldb.formatters.objc.objc.BOOLRef_SummaryProvider",
""));
objc_category_sp->GetSummaryNavigator()->Add(ConstString("BOOL &"),
ObjC_BOOLRef_summary);
lldb::TypeSummaryImplSP ObjC_BOOLPtr_summary(new ScriptSummaryFormat(objc_flags,
"lldb.formatters.objc.objc.BOOLPtr_SummaryProvider",
""));
objc_category_sp->GetSummaryNavigator()->Add(ConstString("BOOL *"),
ObjC_BOOLPtr_summary);
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
// we need to skip pointers here since we are special casing a SEL* when retrieving its value
objc_flags.SetSkipPointers(true);
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
AddScriptSummary(objc_category_sp, "lldb.formatters.objc.Selector.SEL_Summary", ConstString("SEL"), objc_flags);
AddScriptSummary(objc_category_sp, "lldb.formatters.objc.Selector.SEL_Summary", ConstString("struct objc_selector"), objc_flags);
AddScriptSummary(objc_category_sp, "lldb.formatters.objc.Selector.SEL_Summary", ConstString("objc_selector"), objc_flags);
AddScriptSummary(objc_category_sp, "lldb.formatters.objc.Selector.SELPointer_Summary", ConstString("objc_selector *"), objc_flags);
AddScriptSummary(objc_category_sp, "lldb.formatters.objc.Class.Class_Summary", ConstString("Class"), objc_flags);
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
objc_flags.SetSkipPointers(false);
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
TypeCategoryImpl::SharedPointer corefoundation_category_sp = GetCategory(m_corefoundation_category_name);
AddSummary(corefoundation_category_sp,
"${var.years} years, ${var.months} months, ${var.days} days, ${var.hours} hours, ${var.minutes} minutes ${var.seconds} seconds",
ConstString("CFGregorianUnits"),
objc_flags);
AddSummary(corefoundation_category_sp,
"location=${var.location} length=${var.length}",
ConstString("CFRange"),
objc_flags);
AddSummary(corefoundation_category_sp,
(a) adding an introspection formatter for NS(Mutable)IndexSet (b) fixes and improvements to the formatters for NSDate and NSString (c) adding an introspection formatter for NSCountedSet (d) making the Objective-C formatters test cases pass on both 64 and 32 bit one of the test cases is marked as expected failure on i386 - support needs to be added to the LLDB core for it to pass llvm-svn: 151826
2012-03-02 03:32:33 +08:00
"(x=${var.x}, y=${var.y})",
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
ConstString("NSPoint"),
objc_flags);
AddSummary(corefoundation_category_sp,
"location=${var.location}, length=${var.length}",
ConstString("NSRange"),
objc_flags);
AddSummary(corefoundation_category_sp,
"${var.origin}, ${var.size}",
ConstString("NSRect"),
objc_flags);
AddSummary(corefoundation_category_sp,
"(${var.origin}, ${var.size}), ...",
ConstString("NSRectArray"),
objc_flags);
AddSummary(objc_category_sp,
(a) adding an introspection formatter for NS(Mutable)IndexSet (b) fixes and improvements to the formatters for NSDate and NSString (c) adding an introspection formatter for NSCountedSet (d) making the Objective-C formatters test cases pass on both 64 and 32 bit one of the test cases is marked as expected failure on i386 - support needs to be added to the LLDB core for it to pass llvm-svn: 151826
2012-03-02 03:32:33 +08:00
"(width=${var.width}, height=${var.height})",
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
ConstString("NSSize"),
objc_flags);
TypeCategoryImpl::SharedPointer coregraphics_category_sp = GetCategory(m_coregraphics_category_name);
AddSummary(coregraphics_category_sp,
"(width=${var.width}, height=${var.height})",
ConstString("CGSize"),
objc_flags);
AddSummary(coregraphics_category_sp,
"(x=${var.x}, y=${var.y})",
ConstString("CGPoint"),
objc_flags);
AddSummary(coregraphics_category_sp,
"origin=${var.origin} size=${var.size}",
ConstString("CGRect"),
objc_flags);
TypeCategoryImpl::SharedPointer coreservices_category_sp = GetCategory(m_coreservices_category_name);
AddSummary(coreservices_category_sp,
"red=${var.red} green=${var.green} blue=${var.blue}",
ConstString("RGBColor"),
objc_flags);
AddSummary(coreservices_category_sp,
"(t=${var.top}, l=${var.left}, b=${var.bottom}, r=${var.right})",
ConstString("Rect"),
objc_flags);
AddSummary(coreservices_category_sp,
"(v=${var.v}, h=${var.h})",
ConstString("Point"),
objc_flags);
AddSummary(coreservices_category_sp,
"${var.month}/${var.day}/${var.year} ${var.hour} :${var.minute} :${var.second} dayOfWeek:${var.dayOfWeek}",
ConstString("DateTimeRect *"),
objc_flags);
AddSummary(coreservices_category_sp,
"${var.ld.month}/${var.ld.day}/${var.ld.year} ${var.ld.hour} :${var.ld.minute} :${var.ld.second} dayOfWeek:${var.ld.dayOfWeek}",
ConstString("LongDateRect"),
objc_flags);
AddSummary(coreservices_category_sp,
"(x=${var.x}, y=${var.y})",
ConstString("HIPoint"),
objc_flags);
AddSummary(coreservices_category_sp,
"origin=${var.origin} size=${var.size}",
ConstString("HIRect"),
objc_flags);
This patch provides a set of formatters for most of the commonly used Cocoa classes. The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation. A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit. The formatters are contained in a category named "AppKit", which is not enabled at startup. llvm-svn: 151299
2012-02-24 07:10:03 +08:00
TypeCategoryImpl::SharedPointer appkit_category_sp = GetCategory(m_appkit_category_name);
TypeSummaryImpl::Flags appkit_flags;
appkit_flags.SetCascades(true)
.SetSkipPointers(false)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(false)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false);
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFArray.CFArray_SummaryProvider", ConstString("NSArray"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFArray.CFArray_SummaryProvider", ConstString("__NSArrayI"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFArray.CFArray_SummaryProvider", ConstString("__NSArrayM"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFArray.CFArray_SummaryProvider", ConstString("__NSCFArray"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFArray.CFArray_SummaryProvider", ConstString("CFArrayRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFArray.CFArray_SummaryProvider", ConstString("CFMutableArrayRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBag.CFBag_SummaryProvider", ConstString("CFBagRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBag.CFBag_SummaryProvider", ConstString("__CFBag"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBag.CFBag_SummaryProvider", ConstString("const struct __CFBag"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBag.CFBag_SummaryProvider", ConstString("CFMutableBagRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBinaryHeap.CFBinaryHeap_SummaryProvider", ConstString("CFBinaryHeapRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBinaryHeap.CFBinaryHeap_SummaryProvider", ConstString("__CFBinaryHeap"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFDictionary.CFDictionary_SummaryProvider", ConstString("NSDictionary"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFDictionary.CFDictionary_SummaryProvider2", ConstString("CFDictionaryRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFDictionary.CFDictionary_SummaryProvider2", ConstString("CFMutableDictionaryRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFDictionary.CFDictionary_SummaryProvider", ConstString("__NSCFDictionary"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFDictionary.CFDictionary_SummaryProvider", ConstString("__NSDictionaryI"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFDictionary.CFDictionary_SummaryProvider", ConstString("__NSDictionaryM"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("NSString"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("CFStringRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("CFMutableStringRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFAttributedString_SummaryProvider", ConstString("NSAttributedString"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("__NSCFConstantString"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("__NSCFString"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("NSCFConstantString"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("NSCFString"), appkit_flags);
<rdar://problem/11755446> Making sure to provide summaries for one more NSString subclass llvm-svn: 159389
2012-06-29 07:05:43 +08:00
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFString.CFString_SummaryProvider", ConstString("NSPathStore2"), appkit_flags);
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSBundle.NSBundle_SummaryProvider", ConstString("NSBundle"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSData.NSData_SummaryProvider", ConstString("NSData"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSData.NSData_SummaryProvider2", ConstString("CFDataRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSData.NSData_SummaryProvider2", ConstString("CFMutableDataRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSData.NSData_SummaryProvider", ConstString("NSConcreteData"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSData.NSData_SummaryProvider", ConstString("NSConcreteMutableData"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSData.NSData_SummaryProvider", ConstString("__NSCFData"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSException.NSException_SummaryProvider", ConstString("NSException"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSMachPort.NSMachPort_SummaryProvider", ConstString("NSMachPort"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNotification.NSNotification_SummaryProvider", ConstString("NSNotification"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNotification.NSNotification_SummaryProvider", ConstString("NSConcreteNotification"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNumber.NSNumber_SummaryProvider", ConstString("NSNumber"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNumber.NSNumber_SummaryProvider", ConstString("__NSCFBoolean"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNumber.NSNumber_SummaryProvider", ConstString("__NSCFNumber"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNumber.NSNumber_SummaryProvider", ConstString("NSCFBoolean"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSNumber.NSNumber_SummaryProvider", ConstString("NSCFNumber"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider", ConstString("NSSet"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider2", ConstString("CFSetRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider2", ConstString("CFMutableSetRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider", ConstString("__NSCFSet"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider", ConstString("__NSSetI"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider", ConstString("__NSSetM"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSSet.NSSet_SummaryProvider", ConstString("NSCountedSet"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSURL.NSURL_SummaryProvider", ConstString("NSURL"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSURL.NSURL_SummaryProvider", ConstString("CFURLRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSDate_SummaryProvider", ConstString("NSDate"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSDate_SummaryProvider", ConstString("__NSDate"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSDate_SummaryProvider", ConstString("__NSTaggedDate"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSDate_SummaryProvider", ConstString("NSCalendarDate"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSTimeZone_SummaryProvider", ConstString("NSTimeZone"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSTimeZone_SummaryProvider", ConstString("CFTimeZoneRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.NSTimeZone_SummaryProvider", ConstString("__NSTimeZone"), appkit_flags);
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
(a) adding an introspection formatter for NS(Mutable)IndexSet (b) fixes and improvements to the formatters for NSDate and NSString (c) adding an introspection formatter for NSCountedSet (d) making the Objective-C formatters test cases pass on both 64 and 32 bit one of the test cases is marked as expected failure on i386 - support needs to be added to the LLDB core for it to pass llvm-svn: 151826
2012-03-02 03:32:33 +08:00
// CFAbsoluteTime is actually a double rather than a pointer to an object
// we do not care about the numeric value, since it is probably meaningless to users
appkit_flags.SetDontShowValue(true);
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSDate.CFAbsoluteTime_SummaryProvider", ConstString("CFAbsoluteTime"), appkit_flags);
(a) adding an introspection formatter for NS(Mutable)IndexSet (b) fixes and improvements to the formatters for NSDate and NSString (c) adding an introspection formatter for NSCountedSet (d) making the Objective-C formatters test cases pass on both 64 and 32 bit one of the test cases is marked as expected failure on i386 - support needs to be added to the LLDB core for it to pass llvm-svn: 151826
2012-03-02 03:32:33 +08:00
appkit_flags.SetDontShowValue(false);
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSIndexSet.NSIndexSet_SummaryProvider", ConstString("NSIndexSet"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.NSIndexSet.NSIndexSet_SummaryProvider", ConstString("NSMutableIndexSet"), appkit_flags);
(a) adding an introspection formatter for NS(Mutable)IndexSet (b) fixes and improvements to the formatters for NSDate and NSString (c) adding an introspection formatter for NSCountedSet (d) making the Objective-C formatters test cases pass on both 64 and 32 bit one of the test cases is marked as expected failure on i386 - support needs to be added to the LLDB core for it to pass llvm-svn: 151826
2012-03-02 03:32:33 +08:00
(a) adding formatters for: NSTimeZone and CFTimeZonRef SEL and related types CFGregorianDate llvm-svn: 151866
2012-03-02 08:55:53 +08:00
AddSummary(appkit_category_sp, "@\"${var.month%d}/${var.day%d}/${var.year%d} ${var.hour%d}:${var.minute%d}:${var.second}\"", ConstString("CFGregorianDate"), appkit_flags);
Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing llvm-svn: 155563
2012-04-26 01:53:41 +08:00
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBitVector.CFBitVector_SummaryProvider", ConstString("CFBitVectorRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBitVector.CFBitVector_SummaryProvider", ConstString("CFMutableBitVectorRef"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBitVector.CFBitVector_SummaryProvider", ConstString("__CFBitVector"), appkit_flags);
AddScriptSummary(appkit_category_sp, "lldb.formatters.objc.CFBitVector.CFBitVector_SummaryProvider", ConstString("__CFMutableBitVector"), appkit_flags);
added a new formatter for CF(Mutable)BitVector fixed a few potential NULL-pointer derefs in ValueObject we have a way to provide docstrings for properties we add to the SWIG layer - a few of these properties have a docstring already, more will come in future commits added a new bunch of properties to SBData to make it more natural and Python-like to access the data they contain llvm-svn: 151962
2012-03-03 08:45:57 +08:00
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above llvm-svn: 150784
2012-02-17 11:18:30 +08:00
TypeCategoryImpl::SharedPointer vectors_category_sp = GetCategory(m_vectortypes_category_name);
TypeSummaryImpl::Flags vector_flags;
vector_flags.SetCascades(true)
.SetSkipPointers(true)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(false)
.SetShowMembersOneLiner(true)
.SetHideItemNames(true);
AddSummary(vectors_category_sp,
"${var.uint128}",
ConstString("builtin_type_vec128"),
objc_flags);
AddSummary(vectors_category_sp,
"",
ConstString("float [4]"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("int32_t [4]"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("int16_t [8]"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vDouble"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vFloat"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vSInt8"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vSInt16"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vSInt32"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vUInt16"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vUInt8"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vUInt16"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vUInt32"),
vector_flags);
AddSummary(vectors_category_sp,
"",
ConstString("vBool32"),
vector_flags);
Fix preprocessor warnings for no newline at the end of the source files. llvm-svn: 141755
2011-10-12 08:53:29 +08:00
}
Patch Enrico's changes from r150558 on 2012-02-14 to build even if Python is not available (LLDB_DISABLE_PYTHON is defined). Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if this build is LLDB_DISABLE_PYTHON. Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj to only do this copying for Mac native builds. llvm-svn: 151035
2012-02-21 13:33:55 +08:00
#endif // LLDB_DISABLE_PYTHON