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

229 lines
7.8 KiB
C++
Raw Normal View History

Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
//===-- OptionGroupValueObjectDisplay.cpp -----------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Headers have been moved to /includes/lldb/Interpreter. This patch reflects this change. Marco Minutoli <mminutoli@gmail.com> llvm-svn: 131306
2011-05-14 04:21:08 +08:00
#include "lldb/Interpreter/OptionGroupValueObjectDisplay.h"
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
<rdar://problem/14393032> DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
2013-10-01 03:11:51 +08:00
#include "lldb/DataFormatters/ValueObjectPrinter.h"
Delete some more dead includes. This breaks the cycle between Target and PluginLanguageC++, reducing the overall cycle count from 43 to 42. llvm-svn: 298561
2017-03-23 07:33:16 +08:00
#include "lldb/Host/OptionParser.h"
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "lldb/Target/Target.h"
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
Convert option tables to ArrayRefs. This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 llvm-svn: 282188
2016-09-23 04:22:55 +08:00
#include "llvm/ADT/ArrayRef.h"
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
using namespace lldb;
using namespace lldb_private;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
OptionGroupValueObjectDisplay::OptionGroupValueObjectDisplay() {}
OptionGroupValueObjectDisplay::~OptionGroupValueObjectDisplay() {}
static OptionDefinition g_option_table[] = {
{LLDB_OPT_SET_1, false, "dynamic-type", 'd',
OptionParser::eRequiredArgument, nullptr, g_dynamic_value_types, 0,
eArgTypeNone, "Show the object as its full dynamic type, not its static "
"type, if available."},
{LLDB_OPT_SET_1, false, "synthetic-type", 'S',
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeBoolean,
"Show the object obeying its synthetic provider, if available."},
{LLDB_OPT_SET_1, false, "depth", 'D', OptionParser::eRequiredArgument,
nullptr, nullptr, 0, eArgTypeCount, "Set the max recurse depth when "
"dumping aggregate types (default is "
"infinity)."},
{LLDB_OPT_SET_1, false, "flat", 'F', OptionParser::eNoArgument, nullptr,
nullptr, 0, eArgTypeNone, "Display results in a flat format that uses "
"expression paths for each variable or member."},
{LLDB_OPT_SET_1, false, "location", 'L', OptionParser::eNoArgument, nullptr,
nullptr, 0, eArgTypeNone, "Show variable location information."},
{LLDB_OPT_SET_1, false, "object-description", 'O',
OptionParser::eNoArgument, nullptr, nullptr, 0, eArgTypeNone,
"Print as an Objective-C object."},
{LLDB_OPT_SET_1, false, "ptr-depth", 'P', OptionParser::eRequiredArgument,
nullptr, nullptr, 0, eArgTypeCount, "The number of pointers to be "
"traversed when dumping values "
"(default is zero)."},
{LLDB_OPT_SET_1, false, "show-types", 'T', OptionParser::eNoArgument,
nullptr, nullptr, 0, eArgTypeNone,
"Show variable types when dumping values."},
{LLDB_OPT_SET_1, false, "no-summary-depth", 'Y',
OptionParser::eOptionalArgument, nullptr, nullptr, 0, eArgTypeCount,
"Set the depth at which omitting summary information stops (default is "
"1)."},
{LLDB_OPT_SET_1, false, "raw-output", 'R', OptionParser::eNoArgument,
nullptr, nullptr, 0, eArgTypeNone, "Don't use formatting options."},
{LLDB_OPT_SET_1, false, "show-all-children", 'A', OptionParser::eNoArgument,
nullptr, nullptr, 0, eArgTypeNone,
"Ignore the upper bound on the number of children to show."},
{LLDB_OPT_SET_1, false, "validate", 'V', OptionParser::eRequiredArgument,
nullptr, nullptr, 0, eArgTypeBoolean, "Show results of type validators."},
{LLDB_OPT_SET_1, false, "element-count", 'Z',
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeCount,
"Treat the result of the expression as if its type is an array of this "
Convert option tables to ArrayRefs. This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 llvm-svn: 282188
2016-09-23 04:22:55 +08:00
"many values."}};
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
Convert option tables to ArrayRefs. This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 llvm-svn: 282188
2016-09-23 04:22:55 +08:00
llvm::ArrayRef<OptionDefinition>
OptionGroupValueObjectDisplay::GetDefinitions() {
Try to fix build errors on Android. It doesn't like the implicit conversion from T[] to ArrayRef<T> so I'm using `llvm::makeArrayRef()`. Hopefully I got everything. llvm-svn: 282195
2016-09-23 05:06:13 +08:00
return llvm::makeArrayRef(g_option_table);
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Error OptionGroupValueObjectDisplay::SetOptionValue(
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
uint32_t option_idx, llvm::StringRef option_arg,
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ExecutionContext *execution_context) {
Error error;
const int short_option = g_option_table[option_idx].short_option;
bool success = false;
switch (short_option) {
case 'd': {
int32_t result;
result =
Args::StringToOptionEnum(option_arg, g_dynamic_value_types, 2, error);
if (error.Success())
use_dynamic = (lldb::DynamicValueType)result;
} break;
case 'T':
show_types = true;
break;
case 'L':
show_location = true;
break;
case 'F':
flat_output = true;
break;
case 'O':
use_objc = true;
break;
case 'R':
be_raw = true;
break;
case 'A':
ignore_cap = true;
break;
case 'D':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
if (option_arg.getAsInteger(0, max_depth)) {
max_depth = UINT32_MAX;
error.SetErrorStringWithFormat("invalid max depth '%s'",
option_arg.str().c_str());
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
case 'Z':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
if (option_arg.getAsInteger(0, elem_count)) {
elem_count = UINT32_MAX;
error.SetErrorStringWithFormat("invalid element count '%s'",
option_arg.str().c_str());
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
case 'P':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
if (option_arg.getAsInteger(0, ptr_depth)) {
ptr_depth = 0;
error.SetErrorStringWithFormat("invalid pointer depth '%s'",
option_arg.str().c_str());
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
case 'Y':
Try to fix failing TestDataFormatterSkipSummary test case. llvm-svn: 282270
2016-09-24 02:11:03 +08:00
if (option_arg.empty())
no_summary_depth = 1;
else if (option_arg.getAsInteger(0, no_summary_depth)) {
Try again to match the logic of the code before re-writing. llvm-svn: 282271
2016-09-24 02:13:18 +08:00
no_summary_depth = 0;
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
error.SetErrorStringWithFormat("invalid pointer depth '%s'",
option_arg.str().c_str());
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
case 'S':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
use_synth = Args::StringToBoolean(option_arg, true, &success);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (!success)
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
error.SetErrorStringWithFormat("invalid synthetic-type '%s'",
option_arg.str().c_str());
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
case 'V':
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
run_validator = Args::StringToBoolean(option_arg, true, &success);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (!success)
Update OptionGroup::SetValue to take StringRef. Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 llvm-svn: 282265
2016-09-24 01:48:13 +08:00
error.SetErrorStringWithFormat("invalid validate '%s'",
option_arg.str().c_str());
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
default:
error.SetErrorStringWithFormat("unrecognized option '%c'", short_option);
break;
}
return error;
Added a new OptionValue subclass for lldb::Format: OptionValueFormat. Added new OptionGroup subclasses for: - output file for use with options: long opts: --outfile <path> --append--output short opts: -o <path> -A - format for use with options: long opts: --format <format> - variable object display controls for depth, pointer depth, wether to show types, show summary, show location, flat output, use objc "po" style summary. Modified ValueObjectMemory to be able to be created either with a TypeSP or a ClangASTType. Switched "memory read" over to use OptionGroup subclasses: one for the outfile options, one for the command specific options, and one for the format. llvm-svn: 130334
2011-04-28 06:04:39 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void OptionGroupValueObjectDisplay::OptionParsingStarting(
ExecutionContext *execution_context) {
// If these defaults change, be sure to modify AnyOptionWasSet().
show_types = false;
no_summary_depth = 0;
show_location = false;
flat_output = false;
use_objc = false;
max_depth = UINT32_MAX;
ptr_depth = 0;
elem_count = 0;
use_synth = true;
be_raw = false;
ignore_cap = false;
run_validator = false;
TargetSP target_sp =
execution_context ? execution_context->GetTargetSP() : TargetSP();
if (target_sp)
use_dynamic = target_sp->GetPreferDynamicValue();
else {
// If we don't have any targets, then dynamic values won't do us much good.
use_dynamic = lldb::eNoDynamicValues;
}
Headers have been moved to /includes/lldb/Interpreter. This patch reflects this change. Marco Minutoli <mminutoli@gmail.com> llvm-svn: 131306
2011-05-14 04:21:08 +08:00
}
Our commands that end up displaying a ValueObject as part of their workflow use OptionGroupValueObjectDisplay as their currency for deciding the final representation ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code This checkin provides one and only one (and hopefully correct :-) entry point for this conversion llvm-svn: 178044
2013-03-27 02:04:53 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
DumpValueObjectOptions OptionGroupValueObjectDisplay::GetAsDumpOptions(
LanguageRuntimeDescriptionDisplayVerbosity lang_descr_verbosity,
lldb::Format format, lldb::TypeSummaryImplSP summary_sp) {
DumpValueObjectOptions options;
options.SetMaximumPointerDepth(
{DumpValueObjectOptions::PointerDepth::Mode::Always, ptr_depth});
if (use_objc)
options.SetShowSummary(false);
else
options.SetOmitSummaryDepth(no_summary_depth);
options.SetMaximumDepth(max_depth)
.SetShowTypes(show_types)
.SetShowLocation(show_location)
.SetUseObjectiveC(use_objc)
.SetUseDynamicType(use_dynamic)
.SetUseSyntheticValue(use_synth)
.SetFlatOutput(flat_output)
.SetIgnoreCap(ignore_cap)
.SetFormat(format)
.SetSummary(summary_sp);
if (lang_descr_verbosity ==
eLanguageRuntimeDescriptionDisplayVerbosityCompact)
options.SetHideRootType(use_objc).SetHideName(use_objc).SetHideValue(
use_objc);
if (be_raw)
options.SetRawDisplay();
options.SetRunValidator(run_validator);
options.SetElementCount(elem_count);
return options;
Our commands that end up displaying a ValueObject as part of their workflow use OptionGroupValueObjectDisplay as their currency for deciding the final representation ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code This checkin provides one and only one (and hopefully correct :-) entry point for this conversion llvm-svn: 178044
2013-03-27 02:04:53 +08:00
}