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

1175 lines
43 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.
//
//===----------------------------------------------------------------------===//
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
#include "lldb/DataFormatters/FormatManager.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
// 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"
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
#include "lldb/DataFormatters/FormattersHelpers.h"
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
#include "lldb/DataFormatters/LanguageCategory.h"
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
#include "lldb/Target/ExecutionContext.h"
Move the C++ data formatters to the C++ language plugin llvm-svn: 246873
2015-09-05 05:01:18 +08:00
#include "lldb/Target/Language.h"
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
#include "lldb/Target/Platform.h"
lldb: remove adhoc implementation of array_sizeof Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
2014-06-27 13:17:41 +08:00
#include "llvm/ADT/STLExtras.h"
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
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
#include <initializer_list>
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;
Move the functions that FormatManager uses to actually load formatters into their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
2015-09-02 09:21:31 +08:00
using namespace lldb_private::formatters;
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[]" },
Resubmit: RenderScript command for printing allocation contents Previous commit r250281 broke TestDataFormatterSmartArray.py Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager. Differential Revision: http://reviews.llvm.org/D13730 llvm-svn: 250499
2015-10-16 16:28:47 +08:00
{ eFormatVectorOfFloat16, '\0' , "float16[]" },
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
};
lldb: remove adhoc implementation of array_sizeof Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
2014-06-27 13:17:41 +08:00
static uint32_t g_num_format_infos = llvm::array_lengthof(g_format_infos);
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 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
Move the C++ data formatters to the C++ language plugin llvm-svn: 246873
2015-09-05 05:01:18 +08:00
void
FormatManager::EnableAllCategories ()
{
m_categories_map.EnableAllCategories ();
Mutex::Locker lang_locker(m_language_categories_mutex);
for (auto& iter : m_language_categories_map)
{
if (iter.second)
iter.second->Enable();
}
}
void
FormatManager::DisableAllCategories ()
{
m_categories_map.DisableAllCategories ();
Mutex::Locker lang_locker(m_language_categories_mutex);
for (auto& iter : m_language_categories_map)
{
if (iter.second)
iter.second->Disable();
}
}
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
void
FormatManager::GetPossibleMatches (ValueObject& valobj,
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
CompilerType compiler_type,
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
uint32_t reason,
lldb::DynamicValueType use_dynamic,
FormattersMatchVector& entries,
bool did_strip_ptr,
bool did_strip_ref,
bool did_strip_typedef,
bool root_level)
{
Add {TypeSystem|CompilerType}::GetTypeForFormatters() Different type system may have different notions of attributes of a type that do not matter for data formatters matching purposes For instance, in the case of clang types, we remove some qualifiers (e.g. "volatile") as it doesn't make much sense to differentiate volatile T from T in the data formatters This new API allows each type system to generate, if needed, a type that does not have those unwanted attributes that the data formatters can then consume to generate matches llvm-svn: 248359
2015-09-23 09:39:46 +08:00
compiler_type = compiler_type.GetTypeForFormatters();
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
ConstString type_name(compiler_type.GetConstTypeName());
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
if (valobj.GetBitfieldBitSize() > 0)
{
StreamString sstring;
sstring.Printf("%s:%d",type_name.AsCString(),valobj.GetBitfieldBitSize());
ConstString bitfieldname = ConstString(sstring.GetData());
entries.push_back({bitfieldname,0,did_strip_ptr,did_strip_ref,did_strip_typedef});
reason |= lldb_private::eFormatterChoiceCriterionStrippedBitField;
}
Introduce the concept of a "display name" for types Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
2014-05-18 03:14:17 +08:00
Introduce the concept of a type that is meaningless without dynamic resolution, which are essentially placeholder types meant to appease a language's type system but do not offer any actual information to the debugger, unless further resolved This is currently meant for data formatters to know to ignore such types in caching and lookup llvm-svn: 250767
2015-10-20 08:13:19 +08:00
if (!compiler_type.IsMeaninglessWithoutDynamicResolution())
{
entries.push_back({type_name,reason,did_strip_ptr,did_strip_ref,did_strip_typedef});
ConstString display_type_name(compiler_type.GetDisplayTypeName());
if (display_type_name != type_name)
entries.push_back({display_type_name,reason,did_strip_ptr,did_strip_ref,did_strip_typedef});
}
Introduce the concept of a "display name" for types Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
2014-05-18 03:14:17 +08:00
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
for (bool is_rvalue_ref = true, j = true; j && compiler_type.IsReferenceType(nullptr, &is_rvalue_ref); j = false)
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
{
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
CompilerType non_ref_type = compiler_type.GetNonReferenceType();
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
GetPossibleMatches(valobj,
non_ref_type,
reason | lldb_private::eFormatterChoiceCriterionStrippedPointerReference,
use_dynamic,
entries,
did_strip_ptr,
true,
did_strip_typedef);
<rdar://problem/12055586> Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
2014-04-10 08:14:07 +08:00
if (non_ref_type.IsTypedefType())
{
ClangASTType is now CompilerType. This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
2015-08-12 06:53:00 +08:00
CompilerType deffed_referenced_type = non_ref_type.GetTypedefedType();
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions. This cleans up type systems to be more pluggable. Prior to this we had issues: - Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()" - Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem - Cleaned up Module so that it no longer has dedicated type system member variables: lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module. lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module. Now we have a type system map: typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap; TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module - Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract: class CompilerType { ... //---------------------------------------------------------------------- // Return a new CompilerType that is a L value reference to this type if // this type is valid and the type system supports L value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetLValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType that is a R value reference to this type if // this type is valid and the type system supports R value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetRValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a const modifier to this type if // this type is valid and the type system supports const modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddConstModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a volatile modifier to this type if // this type is valid and the type system supports volatile modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddVolatileModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a restrict modifier to this type if // this type is valid and the type system supports restrict modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddRestrictModifier () const; //---------------------------------------------------------------------- // Create a typedef to this type using "name" as the name of the typedef // this type is valid and the type system supports typedefs, else return // an invalid type. //---------------------------------------------------------------------- CompilerType CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const; }; Other changes include: - Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);" - Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed llvm-svn: 247953
2015-09-18 06:23:34 +08:00
deffed_referenced_type = is_rvalue_ref ? deffed_referenced_type.GetRValueReferenceType() : deffed_referenced_type.GetLValueReferenceType();
<rdar://problem/12055586> Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
2014-04-10 08:14:07 +08:00
GetPossibleMatches(valobj,
deffed_referenced_type,
reason | lldb_private::eFormatterChoiceCriterionNavigatedTypedefs,
use_dynamic,
entries,
did_strip_ptr,
did_strip_ref,
true); // this is not exactly the usual meaning of stripping typedefs
}
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
}
<rdar://problem/12055586> Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
2014-04-10 08:14:07 +08:00
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
if (compiler_type.IsPointerType())
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
{
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
CompilerType non_ptr_type = compiler_type.GetPointeeType();
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
GetPossibleMatches(valobj,
non_ptr_type,
reason | lldb_private::eFormatterChoiceCriterionStrippedPointerReference,
use_dynamic,
entries,
true,
did_strip_ref,
did_strip_typedef);
<rdar://problem/12055586> Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
2014-04-10 08:14:07 +08:00
if (non_ptr_type.IsTypedefType())
{
ClangASTType is now CompilerType. This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
2015-08-12 06:53:00 +08:00
CompilerType deffed_pointed_type = non_ptr_type.GetTypedefedType().GetPointerType();
<rdar://problem/12055586> Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
2014-04-10 08:14:07 +08:00
GetPossibleMatches(valobj,
deffed_pointed_type,
reason | lldb_private::eFormatterChoiceCriterionNavigatedTypedefs,
use_dynamic,
entries,
did_strip_ptr,
did_strip_ref,
true); // this is not exactly the usual meaning of stripping typedefs
}
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
}
Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
2015-09-09 09:10:46 +08:00
for (lldb::LanguageType language_type : GetCandidateLanguages(valobj))
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
{
Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
2015-09-09 09:10:46 +08:00
if (Language* language = Language::FindPlugin(language_type))
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
{
Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
2015-09-09 09:10:46 +08:00
for (ConstString candidate : language->GetPossibleFormattersMatches(valobj, use_dynamic))
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
{
Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
2015-09-09 09:10:46 +08:00
entries.push_back({candidate,
reason | lldb_private::eFormatterChoiceCriterionLanguagePlugin,
did_strip_ptr,
did_strip_ref,
did_strip_typedef});
}
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
}
}
Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
2015-09-09 09:10:46 +08:00
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
// try to strip typedef chains
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
if (compiler_type.IsTypedefType())
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
{
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
CompilerType deffed_type = compiler_type.GetTypedefedType();
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
GetPossibleMatches(valobj,
deffed_type,
reason | lldb_private::eFormatterChoiceCriterionNavigatedTypedefs,
use_dynamic,
entries,
did_strip_ptr,
did_strip_ref,
true);
}
if (root_level)
{
do {
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
if (!compiler_type.IsValid())
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
break;
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
CompilerType unqual_compiler_ast_type = compiler_type.GetFullyUnqualifiedType();
if (!unqual_compiler_ast_type.IsValid())
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
break;
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
if (unqual_compiler_ast_type.GetOpaqueQualType() != compiler_type.GetOpaqueQualType())
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
GetPossibleMatches (valobj,
DataFormatters: Rename clang_type to compiler_type. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
2015-09-18 02:43:40 +08:00
unqual_compiler_ast_type,
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
reason,
use_dynamic,
entries,
did_strip_ptr,
did_strip_ref,
did_strip_typedef);
} while(false);
// if all else fails, go to static type
if (valobj.IsDynamic())
{
lldb::ValueObjectSP static_value_sp(valobj.GetStaticValue());
if (static_value_sp)
GetPossibleMatches(*static_value_sp.get(),
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
static_value_sp->GetCompilerType(),
<rdar://problem/15530080> Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
2013-11-22 08:02:13 +08:00
reason | lldb_private::eFormatterChoiceCriterionWentToStaticValue,
use_dynamic,
entries,
did_strip_ptr,
did_strip_ref,
did_strip_typedef,
true);
}
}
}
<rdar://problem/11778815> Formats (as in "type format") are now included in categories The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable llvm-svn: 192217
2013-10-09 03:03:22 +08:00
lldb::TypeFormatImplSP
FormatManager::GetFormatForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
return lldb::TypeFormatImplSP();
lldb::TypeFormatImplSP format_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::TypeFormatImplSP format_current_sp = category_sp->GetFormatForType(type_sp);
if (format_current_sp && (format_chosen_sp.get() == NULL || (prio_category > category_sp->GetEnabledPosition())))
{
prio_category = category_sp->GetEnabledPosition();
format_chosen_sp = format_current_sp;
}
}
return format_chosen_sp;
}
<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/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
lldb::ScriptedSyntheticChildrenSP
<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
FormatManager::GetSyntheticForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
return lldb::ScriptedSyntheticChildrenSP();
lldb::ScriptedSyntheticChildrenSP synth_chosen_sp;
<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
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;
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
lldb::ScriptedSyntheticChildrenSP synth_current_sp((ScriptedSyntheticChildren*)category_sp->GetSyntheticForType(type_sp).get());
<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
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);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
lldb::ScriptedSyntheticChildrenSP synth_sp = GetSyntheticForType(type_sp);
<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
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
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
lldb::TypeValidatorImplSP
FormatManager::GetValidatorForType (lldb::TypeNameSpecifierImplSP type_sp)
{
if (!type_sp)
return lldb::TypeValidatorImplSP();
lldb::TypeValidatorImplSP validator_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::TypeValidatorImplSP validator_current_sp(category_sp->GetValidatorForType(type_sp).get());
if (validator_current_sp && (validator_chosen_sp.get() == NULL || (prio_category > category_sp->GetEnabledPosition())))
{
prio_category = category_sp->GetEnabledPosition();
validator_chosen_sp = validator_current_sp;
}
}
return validator_chosen_sp;
}
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
void
FormatManager::LoopThroughCategories (CategoryCallback callback, void* param)
{
m_categories_map.LoopThrough(callback, param);
Mutex::Locker locker(m_language_categories_mutex);
for (const auto& entry : m_language_categories_map)
{
if (auto category_sp = entry.second->GetCategory())
{
if (!callback(param, category_sp))
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
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,
A few improvements to our vector types formatting story: - use a hardcoded formatter to match all vector types, and make it so that their element type is taken into account when doing default formatting - special case a vector of char to display byte values instead of characters by default Fixes the test failures Ilia was seeing llvm-svn: 231504
2015-03-07 03:37:57 +08:00
bool can_create)
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_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;
Resubmit: RenderScript command for printing allocation contents Previous commit r250281 broke TestDataFormatterSmartArray.py Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager. Differential Revision: http://reviews.llvm.org/D13730 llvm-svn: 250499
2015-10-16 16:28:47 +08:00
case eFormatVectorOfFloat16:
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
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
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
bool
FormatManager::ShouldPrintAsOneLiner (ValueObject& valobj)
{
<rdar://problem/15319880> Introduce a new boolean setting enable-auto-oneliner This setting if set to false will force LLDB to not use the new compact one-line display By default, one-line mode stays on, at least until we can be confident it works. But now if it seriously impedes your workflow while it evolves/it works wonders but you still hate it, there's a way to turn it off llvm-svn: 193450
2013-10-26 07:09:40 +08:00
// if settings say no oneline whatsoever
Renaming the setting to enable/disable automatic one-lining of summaries as auto-one-line-summaries llvm-svn: 193801
2013-11-01 05:01:07 +08:00
if (valobj.GetTargetSP().get() && valobj.GetTargetSP()->GetDebugger().GetAutoOneLineSummaries() == false)
<rdar://problem/15319880> Introduce a new boolean setting enable-auto-oneliner This setting if set to false will force LLDB to not use the new compact one-line display By default, one-line mode stays on, at least until we can be confident it works. But now if it seriously impedes your workflow while it evolves/it works wonders but you still hate it, there's a way to turn it off llvm-svn: 193450
2013-10-26 07:09:40 +08:00
return false; // then don't oneline
When deciding if one-liner printing applies, and you find a summary, the summary is a good candidate to ask. While in theory one could want one-liner printing with a non-one-liner summary, I don't see LLDB as the best place to solve such inner conflicts llvm-svn: 217641
2014-09-12 07:00:27 +08:00
// if this object has a summary, then ask the summary
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
if (valobj.GetSummaryFormat().get() != nullptr)
When deciding if one-liner printing applies, and you find a summary, the summary is a good candidate to ask. While in theory one could want one-liner printing with a non-one-liner summary, I don't see LLDB as the best place to solve such inner conflicts llvm-svn: 217641
2014-09-12 07:00:27 +08:00
return valobj.GetSummaryFormat()->IsOneLiner();
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
// no children, no party
if (valobj.GetNumChildren() == 0)
return false;
Allow CompilerType to express a vote on whether oneliner printing should happen llvm-svn: 248363
2015-09-23 10:04:34 +08:00
// ask the type if it has any opinion about this
// eLazyBoolCalculate == no opinion; other values should be self explanatory
CompilerType compiler_type(valobj.GetCompilerType());
if (compiler_type.IsValid())
{
switch (compiler_type.ShouldPrintAsOneLiner())
{
case eLazyBoolNo:
return false;
case eLazyBoolYes:
return true;
case eLazyBoolCalculate:
break;
}
}
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
size_t total_children_name_len = 0;
for (size_t idx = 0;
idx < valobj.GetNumChildren();
idx++)
{
If a ValueObject has a child that vends synthetic children, but only does so to generate a value for itself, that's not a disqualifier from one-line printing. Also, fetch synthetic values if available and requested for children as well while printing them llvm-svn: 219427
2014-10-10 02:47:36 +08:00
bool is_synth_val = false;
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
ValueObjectSP child_sp(valobj.GetChildAtIndex(idx, true));
// something is wrong here - bail out
if (!child_sp)
return false;
// if we decided to define synthetic children for a type, we probably care enough
// to show them, but avoid nesting children in children
if (child_sp->GetSyntheticChildren().get() != nullptr)
If a ValueObject has a child that vends synthetic children, but only does so to generate a value for itself, that's not a disqualifier from one-line printing. Also, fetch synthetic values if available and requested for children as well while printing them llvm-svn: 219427
2014-10-10 02:47:36 +08:00
{
ValueObjectSP synth_sp(child_sp->GetSyntheticValue());
// wait.. wat? just get out of here..
if (!synth_sp)
return false;
// but if we only have them to provide a value, keep going
if (synth_sp->MightHaveChildren() == false && synth_sp->DoesProvideSyntheticValue())
is_synth_val = true;
else
return false;
}
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
total_children_name_len += child_sp->GetName().GetLength();
// 50 itself is a "randomly" chosen number - the idea is that
// overly long structs should not get this treatment
// FIXME: maybe make this a user-tweakable setting?
if (total_children_name_len > 50)
return false;
// if a summary is there..
if (child_sp->GetSummaryFormat())
{
// and it wants children, then bail out
Allow summary formatters to take ValueObjects into account when deciding whether values/children should be printed and if child names should be shown This decision has always been statically-bound to the individual formatter. With this patch, the idea is that this decision could potentially be dynamic depending on the ValueObject itself llvm-svn: 207046
2014-04-24 07:16:25 +08:00
if (child_sp->GetSummaryFormat()->DoesPrintChildren(child_sp.get()))
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
return false;
}
One should actually not do one-line printing of nested aggregates even if they are not the base class This check was overly strict. Relax it. While one could conceivably want nested one-lining: (Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14) the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact. Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :) llvm-svn: 193218
2013-10-23 09:34:31 +08:00
// if this child has children..
if (child_sp->GetNumChildren())
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
{
One should actually not do one-line printing of nested aggregates even if they are not the base class This check was overly strict. Relax it. While one could conceivably want nested one-lining: (Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14) the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact. Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :) llvm-svn: 193218
2013-10-23 09:34:31 +08:00
// ...and no summary...
// (if it had a summary and the summary wanted children, we would have bailed out anyway
// so this only makes us bail out if this has no summary and we would then print children)
If a ValueObject has a child that vends synthetic children, but only does so to generate a value for itself, that's not a disqualifier from one-line printing. Also, fetch synthetic values if available and requested for children as well while printing them llvm-svn: 219427
2014-10-10 02:47:36 +08:00
if (!child_sp->GetSummaryFormat() && !is_synth_val) // but again only do that if not a synthetic valued child
One should actually not do one-line printing of nested aggregates even if they are not the base class This check was overly strict. Relax it. While one could conceivably want nested one-lining: (Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14) the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact. Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :) llvm-svn: 193218
2013-10-23 09:34:31 +08:00
return false; // then bail out
<rdar://problem/12042982> This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
2013-10-05 07:14:13 +08:00
}
}
return true;
}
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);
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
ConstString
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
FormatManager::GetTypeForCache (ValueObject& valobj,
lldb::DynamicValueType use_dynamic)
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
Introduce the concept of a type that is meaningless without dynamic resolution, which are essentially placeholder types meant to appease a language's type system but do not offer any actual information to the debugger, unless further resolved This is currently meant for data formatters to know to ignore such types in caching and lookup llvm-svn: 250767
2015-10-20 08:13:19 +08:00
ValueObjectSP valobj_sp = valobj.GetQualifiedRepresentationIfAvailable(use_dynamic, valobj.IsSynthetic());
if (valobj_sp && valobj_sp->GetCompilerType().IsValid())
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
Introduce the concept of a type that is meaningless without dynamic resolution, which are essentially placeholder types meant to appease a language's type system but do not offer any actual information to the debugger, unless further resolved This is currently meant for data formatters to know to ignore such types in caching and lookup llvm-svn: 250767
2015-10-20 08:13:19 +08:00
if (!valobj_sp->GetCompilerType().IsMeaninglessWithoutDynamicResolution())
return valobj_sp->GetQualifiedTypeName();
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
}
return ConstString();
}
Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
2015-09-09 09:10:46 +08:00
std::vector<lldb::LanguageType>
FormatManager::GetCandidateLanguages (ValueObject& valobj)
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
{
lldb::LanguageType lang_type = valobj.GetObjectRuntimeLanguage();
Introduce the notion of an escape helper. Different languages have different notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB This is NFC, other than a code re-org llvm-svn: 247200
2015-09-10 06:30:24 +08:00
return GetCandidateLanguages(lang_type);
}
std::vector<lldb::LanguageType>
FormatManager::GetCandidateLanguages (lldb::LanguageType lang_type)
{
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
switch (lang_type)
{
Move the C++ data formatters to the C++ language plugin llvm-svn: 246873
2015-09-05 05:01:18 +08:00
case lldb::eLanguageTypeC:
case lldb::eLanguageTypeC89:
case lldb::eLanguageTypeC99:
case lldb::eLanguageTypeC11:
case lldb::eLanguageTypeC_plus_plus:
case lldb::eLanguageTypeC_plus_plus_03:
case lldb::eLanguageTypeC_plus_plus_11:
case lldb::eLanguageTypeC_plus_plus_14:
Move Objective-C data formatters to the Objective-C language plugin where they belong llvm-svn: 247627
2015-09-15 06:18:32 +08:00
return {lldb::eLanguageTypeC_plus_plus, lldb::eLanguageTypeObjC};
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
default:
return {lang_type};
}
}
LanguageCategory*
FormatManager::GetCategoryForLanguage (lldb::LanguageType lang_type)
{
Mutex::Locker locker(m_language_categories_mutex);
auto iter = m_language_categories_map.find(lang_type), end = m_language_categories_map.end();
if (iter != end)
return iter->second.get();
LanguageCategory* lang_category = new LanguageCategory(lang_type);
m_language_categories_map[lang_type] = LanguageCategory::UniquePointer(lang_category);
return lang_category;
}
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
lldb::TypeFormatImplSP
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormatManager::GetHardcodedFormat (FormattersMatchData& match_data)
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
TypeFormatImplSP retval_sp;
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->GetHardcoded(*this, match_data, retval_sp))
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
break;
}
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
}
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
return retval_sp;
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
}
<rdar://problem/11778815> Formats (as in "type format") are now included in categories The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable llvm-svn: 192217
2013-10-09 03:03:22 +08:00
lldb::TypeFormatImplSP
FormatManager::GetFormat (ValueObject& valobj,
lldb::DynamicValueType use_dynamic)
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormattersMatchData match_data(valobj, use_dynamic);
<rdar://problem/11778815> Formats (as in "type format") are now included in categories The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable llvm-svn: 192217
2013-10-09 03:03:22 +08:00
TypeFormatImplSP retval;
Create a logging category that is specific to data formatters activity llvm-svn: 249433
2015-10-07 01:55:14 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_DATAFORMATTERS));
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache())
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
{
if (log)
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
log->Printf("\n\n[FormatManager::GetFormat] Looking into cache for type %s", match_data.GetTypeForCache().AsCString("<invalid>"));
if (m_format_cache.GetFormat(match_data.GetTypeForCache(),retval))
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
{
if (log)
{
log->Printf("[FormatManager::GetFormat] Cache search success. Returning.");
if (log->GetDebug())
log->Printf("[FormatManager::GetFormat] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
}
return retval;
}
if (log)
log->Printf("[FormatManager::GetFormat] Cache search failed. Going normal route");
}
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = m_categories_map.GetFormat(match_data);
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetFormat] Search failed. Giving language a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
{
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->Get(match_data, retval))
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
break;
}
}
if (retval)
{
if (log)
log->Printf("[FormatManager::GetFormat] Language search success. Returning.");
return retval;
}
}
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetFormat] Search failed. Giving hardcoded a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = GetHardcodedFormat(match_data);
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
}
When I introduced hard-coded formatters, I made them non-cacheable This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-type caching would not be a good thing On the other hand, that is not always true - sometimes the matching truly is per-type So, introduce a non-cacheable attribute on formatters that decides whether a formatter should or should not be cached. That way, the few formatters that don't want themselves cached can do so, but most formatters (including most hard-coded ones) can cache themselves just fine llvm-svn: 241184
2015-07-02 04:06:40 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache() && (!retval || !retval->NonCacheable()))
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
{
if (log)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf("[FormatManager::GetFormat] Caching %p for type %s",
static_cast<void*>(retval.get()),
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
match_data.GetTypeForCache().AsCString("<invalid>"));
m_format_cache.SetFormat(match_data.GetTypeForCache(),retval);
This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics llvm-svn: 192928
2013-10-18 06:27:19 +08:00
}
if (log && log->GetDebug())
log->Printf("[FormatManager::GetFormat] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
<rdar://problem/11778815> Formats (as in "type format") are now included in categories The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable llvm-svn: 192217
2013-10-09 03:03:22 +08:00
return retval;
}
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
lldb::TypeSummaryImplSP
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormatManager::GetHardcodedSummaryFormat (FormattersMatchData& match_data)
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
TypeSummaryImplSP retval_sp;
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->GetHardcoded(*this, match_data, retval_sp))
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
break;
}
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
}
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
return retval_sp;
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
lldb::TypeSummaryImplSP
FormatManager::GetSummaryFormat (ValueObject& valobj,
lldb::DynamicValueType use_dynamic)
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormattersMatchData match_data(valobj, use_dynamic);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
TypeSummaryImplSP retval;
Create a logging category that is specific to data formatters activity llvm-svn: 249433
2015-10-07 01:55:14 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_DATAFORMATTERS));
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache())
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
if (log)
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
log->Printf("\n\n[FormatManager::GetSummaryFormat] Looking into cache for type %s", match_data.GetTypeForCache().AsCString("<invalid>"));
if (m_format_cache.GetSummary(match_data.GetTypeForCache(),retval))
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
{
if (log)
{
log->Printf("[FormatManager::GetSummaryFormat] Cache search success. Returning.");
Remove the #define USE_CACHE since the formatters cache has been operational for a while now and has not caused issues that warrant disabling it Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users llvm-svn: 184900
2013-06-26 09:03:38 +08:00
if (log->GetDebug())
clean up about 22 warnings messages llvm-svn: 187900
2013-08-08 03:05:15 +08:00
log->Printf("[FormatManager::GetSummaryFormat] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
return retval;
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
if (log)
log->Printf("[FormatManager::GetSummaryFormat] Cache search failed. Going normal route");
}
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = m_categories_map.GetSummaryFormat(match_data);
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetSummaryFormat] Search failed. Giving language a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
{
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->Get(match_data, retval))
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
break;
}
}
if (retval)
{
if (log)
log->Printf("[FormatManager::GetSummaryFormat] Language search success. Returning.");
return retval;
}
}
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetSummaryFormat] Search failed. Giving hardcoded a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = GetHardcodedSummaryFormat(match_data);
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
}
When I introduced hard-coded formatters, I made them non-cacheable This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-type caching would not be a good thing On the other hand, that is not always true - sometimes the matching truly is per-type So, introduce a non-cacheable attribute on formatters that decides whether a formatter should or should not be cached. That way, the few formatters that don't want themselves cached can do so, but most formatters (including most hard-coded ones) can cache themselves just fine llvm-svn: 241184
2015-07-02 04:06:40 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache() && (!retval || !retval->NonCacheable()))
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
if (log)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf("[FormatManager::GetSummaryFormat] Caching %p for type %s",
static_cast<void*>(retval.get()),
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
match_data.GetTypeForCache().AsCString("<invalid>"));
m_format_cache.SetSummary(match_data.GetTypeForCache(),retval);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
}
Remove the #define USE_CACHE since the formatters cache has been operational for a while now and has not caused issues that warrant disabling it Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users llvm-svn: 184900
2013-06-26 09:03:38 +08:00
if (log && log->GetDebug())
clean up about 22 warnings messages llvm-svn: 187900
2013-08-08 03:05:15 +08:00
log->Printf("[FormatManager::GetSummaryFormat] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
return retval;
}
#ifndef LLDB_DISABLE_PYTHON
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
lldb::SyntheticChildrenSP
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormatManager::GetHardcodedSyntheticChildren (FormattersMatchData& match_data)
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
SyntheticChildrenSP retval_sp;
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->GetHardcoded(*this, match_data, retval_sp))
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
break;
}
Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
2014-08-20 02:47:58 +08:00
}
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
return retval_sp;
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
lldb::SyntheticChildrenSP
FormatManager::GetSyntheticChildren (ValueObject& valobj,
Remove the #define USE_CACHE since the formatters cache has been operational for a while now and has not caused issues that warrant disabling it Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users llvm-svn: 184900
2013-06-26 09:03:38 +08:00
lldb::DynamicValueType use_dynamic)
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormattersMatchData match_data(valobj, use_dynamic);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
SyntheticChildrenSP retval;
Create a logging category that is specific to data formatters activity llvm-svn: 249433
2015-10-07 01:55:14 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_DATAFORMATTERS));
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache())
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
if (log)
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
log->Printf("\n\n[FormatManager::GetSyntheticChildren] Looking into cache for type %s", match_data.GetTypeForCache().AsCString("<invalid>"));
if (m_format_cache.GetSynthetic(match_data.GetTypeForCache(),retval))
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
{
if (log)
{
log->Printf("[FormatManager::GetSyntheticChildren] Cache search success. Returning.");
Remove the #define USE_CACHE since the formatters cache has been operational for a while now and has not caused issues that warrant disabling it Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users llvm-svn: 184900
2013-06-26 09:03:38 +08:00
if (log->GetDebug())
clean up about 22 warnings messages llvm-svn: 187900
2013-08-08 03:05:15 +08:00
log->Printf("[FormatManager::GetSyntheticChildren] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
return retval;
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
if (log)
<rdar://problem/12717717> Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*" Also, a couple improvements to the "lldb types" logging llvm-svn: 184215
2013-06-19 02:23:07 +08:00
log->Printf("[FormatManager::GetSyntheticChildren] Cache search failed. Going normal route");
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
}
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = m_categories_map.GetSyntheticChildren(match_data);
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetSyntheticChildren] Search failed. Giving language a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
{
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->Get(match_data, retval))
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
break;
}
}
if (retval)
{
if (log)
log->Printf("[FormatManager::GetSyntheticChildren] Language search success. Returning.");
return retval;
}
}
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetSyntheticChildren] Search failed. Giving hardcoded a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = GetHardcodedSyntheticChildren(match_data);
This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
2013-10-31 07:46:27 +08:00
}
When I introduced hard-coded formatters, I made them non-cacheable This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-type caching would not be a good thing On the other hand, that is not always true - sometimes the matching truly is per-type So, introduce a non-cacheable attribute on formatters that decides whether a formatter should or should not be cached. That way, the few formatters that don't want themselves cached can do so, but most formatters (including most hard-coded ones) can cache themselves just fine llvm-svn: 241184
2015-07-02 04:06:40 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache() && (!retval || !retval->NonCacheable()))
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
{
if (log)
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
log->Printf("[FormatManager::GetSyntheticChildren] Caching %p for type %s",
static_cast<void*>(retval.get()),
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
match_data.GetTypeForCache().AsCString("<invalid>"));
m_format_cache.SetSynthetic(match_data.GetTypeForCache(),retval);
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
}
Remove the #define USE_CACHE since the formatters cache has been operational for a while now and has not caused issues that warrant disabling it Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users llvm-svn: 184900
2013-06-26 09:03:38 +08:00
if (log && log->GetDebug())
clean up about 22 warnings messages llvm-svn: 187900
2013-08-08 03:05:15 +08:00
log->Printf("[FormatManager::GetSyntheticChildren] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
return retval;
}
#endif
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
lldb::TypeValidatorImplSP
FormatManager::GetValidator (ValueObject& valobj,
lldb::DynamicValueType use_dynamic)
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormattersMatchData match_data(valobj, use_dynamic);
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
TypeValidatorImplSP retval;
Create a logging category that is specific to data formatters activity llvm-svn: 249433
2015-10-07 01:55:14 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_DATAFORMATTERS));
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache())
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
{
if (log)
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
log->Printf("\n\n[FormatManager::GetValidator] Looking into cache for type %s", match_data.GetTypeForCache().AsCString("<invalid>"));
if (m_format_cache.GetValidator(match_data.GetTypeForCache(),retval))
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
{
if (log)
{
log->Printf("[FormatManager::GetValidator] Cache search success. Returning.");
if (log->GetDebug())
log->Printf("[FormatManager::GetValidator] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
}
return retval;
}
if (log)
log->Printf("[FormatManager::GetValidator] Cache search failed. Going normal route");
}
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = m_categories_map.GetValidator(match_data);
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetValidator] Search failed. Giving language a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
{
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->Get(match_data, retval))
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
break;
}
}
if (retval)
{
if (log)
log->Printf("[FormatManager::GetValidator] Language search success. Returning.");
return retval;
}
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
if (!retval)
{
if (log)
log->Printf("[FormatManager::GetValidator] Search failed. Giving hardcoded a chance.");
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
retval = GetHardcodedValidator(match_data);
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
}
When I introduced hard-coded formatters, I made them non-cacheable This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-type caching would not be a good thing On the other hand, that is not always true - sometimes the matching truly is per-type So, introduce a non-cacheable attribute on formatters that decides whether a formatter should or should not be cached. That way, the few formatters that don't want themselves cached can do so, but most formatters (including most hard-coded ones) can cache themselves just fine llvm-svn: 241184
2015-07-02 04:06:40 +08:00
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (match_data.GetTypeForCache() && (!retval || !retval->NonCacheable()))
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
{
if (log)
log->Printf("[FormatManager::GetValidator] Caching %p for type %s",
static_cast<void*>(retval.get()),
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
match_data.GetTypeForCache().AsCString("<invalid>"));
m_format_cache.SetValidator(match_data.GetTypeForCache(),retval);
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
}
if (log && log->GetDebug())
log->Printf("[FormatManager::GetValidator] Cache hits: %" PRIu64 " - Cache Misses: %" PRIu64, m_format_cache.GetCacheHits(), m_format_cache.GetCacheMisses());
return retval;
}
lldb::TypeValidatorImplSP
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
FormatManager::GetHardcodedValidator (FormattersMatchData& match_data)
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
TypeValidatorImplSP retval_sp;
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
for (lldb::LanguageType lang_type : match_data.GetCandidateLanguages())
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
{
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
if (LanguageCategory* lang_category = GetCategoryForLanguage(lang_type))
{
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
if (lang_category->GetHardcoded(*this, match_data, retval_sp))
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
break;
}
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
}
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
return retval_sp;
Introduce the notion of a "type validator" formatter Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
2014-09-06 04:45:07 +08:00
}
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
FormatManager::FormatManager() :
m_format_cache(),
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
m_named_summaries_map(this),
m_last_revision(0),
m_categories_map(this),
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-02 02:22:39 +08:00
m_language_categories_map(),
m_language_categories_mutex(Mutex::eMutexTypeRecursive),
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")),
Move hardcoded formatters from the FormatManager to the Language plugins llvm-svn: 247831
2015-09-17 02:28:11 +08:00
m_vectortypes_category_name(ConstString("VectorTypes"))
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();
Move Objective-C data formatters to the Objective-C language plugin where they belong llvm-svn: 247627
2015-09-15 06:18:32 +08:00
LoadVectorFormatters();
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
Add the ability for formatter categories to be bound to one or more languages What that does is it restricts formatters in those categories to only match to types coming from "compatible" source languages llvm-svn: 247872
2015-09-17 08:14:50 +08:00
EnableCategory(m_vectortypes_category_name,TypeCategoryMap::Last, lldb::eLanguageTypeObjC_plus_plus);
EnableCategory(m_system_category_name,TypeCategoryMap::Last, lldb::eLanguageTypeObjC_plus_plus);
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()
{
<rdar://problem/12725746> Providing data formatters for char16_t* and char32_t* C++11-style Unicode strings Using this chance to refactor the UTF data reader used for data formatters for added generality Added a relevant test case llvm-svn: 172119
2013-01-11 06:08:35 +08:00
TypeSummaryImpl::Flags string_flags;
The summary for const char* was not cascading. This was preventing us from providing a summary for the result of std::string.c_str() with libc++ llvm-svn: 175841
2013-02-22 08:37:31 +08:00
string_flags.SetCascades(true)
<rdar://problem/12725746> Providing data formatters for char16_t* and char32_t* C++11-style Unicode strings Using this chance to refactor the UTF data reader used for data formatters for added generality Added a relevant test case llvm-svn: 172119
2013-01-11 06:08:35 +08:00
.SetSkipPointers(true)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(false)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false);
Add a formatter for wchar_t[N] arrays rdar://21299888 llvm-svn: 239777
2015-06-16 07:01:47 +08:00
TypeSummaryImpl::Flags string_array_flags;
There is no reason why this formatter should not cascade. Make it cascade llvm-svn: 243369
2015-07-28 10:13:03 +08:00
string_array_flags.SetCascades(true)
Add a formatter for wchar_t[N] arrays rdar://21299888 llvm-svn: 239777
2015-06-16 07:01:47 +08:00
.SetSkipPointers(true)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(true)
.SetShowMembersOneLiner(false)
.SetHideItemNames(false);
<rdar://problem/12725746> Providing data formatters for char16_t* and char32_t* C++11-style Unicode strings Using this chance to refactor the UTF data reader used for data formatters for added generality Added a relevant test case llvm-svn: 172119
2013-01-11 06:08:35 +08:00
lldb::TypeSummaryImplSP string_format(new StringSummaryFormat(string_flags, "${var%s}"));
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
Add a formatter for wchar_t[N] arrays rdar://21299888 llvm-svn: 239777
2015-06-16 07:01:47 +08:00
lldb::TypeSummaryImplSP string_array_format(new StringSummaryFormat(string_array_flags,
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
"${var%s}"));
lldb::RegularExpressionSP any_size_char_arr(new RegularExpression("char \\[[0-9]+\\]"));
Add a formatter for wchar_t[N] arrays rdar://21299888 llvm-svn: 239777
2015-06-16 07:01:47 +08:00
lldb::RegularExpressionSP any_size_wchar_arr(new RegularExpression("wchar_t \\[[0-9]+\\]"));
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 sys_category_sp = GetCategory(m_system_category_name);
FormatNavigator has long stopped navigating anything - the generation of possible formatters matches is now done elsewhere So, rename the class for what it truly is: a FormattersContainer Also do a bunch of related text substitutions in the interest of overall naming clarity llvm-svn: 197795
2013-12-20 17:38:13 +08:00
sys_category_sp->GetTypeSummariesContainer()->Add(ConstString("char *"), string_format);
sys_category_sp->GetTypeSummariesContainer()->Add(ConstString("unsigned char *"), string_format);
sys_category_sp->GetRegexTypeSummariesContainer()->Add(any_size_char_arr, string_array_format);
Get rid of the FooStructSynth, it was a testing thing I put in and forgot to remove Hopefully nobody had a struct Foo in their app:-) llvm-svn: 193092
2013-10-22 01:29:51 +08:00
<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}"));
FormatNavigator has long stopped navigating anything - the generation of possible formatters matches is now done elsewhere So, rename the class for what it truly is: a FormattersContainer Also do a bunch of related text substitutions in the interest of overall naming clarity llvm-svn: 197795
2013-12-20 17:38:13 +08:00
sys_category_sp->GetTypeSummariesContainer()->Add(ConstString("OSType"), ostype_summary);
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
Add ifdef LLDB_DISABLE_PYTHON around newly added use of AddCXXSummary in FormatManager::LoadSystemFormatters(); that function pulls in code that assumes python; can't be used without the ifdef. llvm-svn: 172300
2013-01-12 12:24:50 +08:00
#ifndef LLDB_DISABLE_PYTHON
<rdar://problem/12632394> Add a format for FourCharCode This is now safe to do thanks to the "formats in categories" feature llvm-svn: 192233
2013-10-09 04:59:02 +08:00
TypeFormatImpl::Flags fourchar_flags;
fourchar_flags.SetCascades(true).SetSkipPointers(true).SetSkipReferences(true);
AddFormat(sys_category_sp, lldb::eFormatOSType, ConstString("FourCharCode"), fourchar_flags);
Add ifdef LLDB_DISABLE_PYTHON around newly added use of AddCXXSummary in FormatManager::LoadSystemFormatters(); that function pulls in code that assumes python; can't be used without the ifdef. llvm-svn: 172300
2013-01-12 12:24:50 +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
}
<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray llvm-svn: 163818
2012-09-14 02:27:09 +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
void
Move Objective-C data formatters to the Objective-C language plugin where they belong llvm-svn: 247627
2015-09-15 06:18:32 +08:00
FormatManager::LoadVectorFormatters()
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);
Move Objective-C data formatters to the Objective-C language plugin where they belong llvm-svn: 247627
2015-09-15 06:18:32 +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
TypeSummaryImpl::Flags vector_flags;
vector_flags.SetCascades(true)
.SetSkipPointers(true)
.SetSkipReferences(false)
.SetDontShowChildren(true)
.SetDontShowValue(false)
.SetShowMembersOneLiner(true)
.SetHideItemNames(true);
<rdar://problem/12709976> Adding a summary for NSError llvm-svn: 169792
2012-12-11 07:30:25 +08:00
AddStringSummary(vectors_category_sp,
"${var.uint128}",
ConstString("builtin_type_vec128"),
Move Objective-C data formatters to the Objective-C language plugin where they belong llvm-svn: 247627
2015-09-15 06:18:32 +08:00
vector_flags);
<rdar://problem/12709976> Adding a summary for NSError llvm-svn: 169792
2012-12-11 07:30:25 +08:00
AddStringSummary(vectors_category_sp,
"",
ConstString("float [4]"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("int32_t [4]"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("int16_t [8]"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vDouble"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vFloat"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vSInt8"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vSInt16"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vSInt32"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vUInt16"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vUInt8"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vUInt16"),
vector_flags);
AddStringSummary(vectors_category_sp,
"",
ConstString("vUInt32"),
vector_flags);
AddStringSummary(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
}