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/OptionValueSInt64.cpp

82 lines
2.5 KiB
C++
Raw Normal View History

Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
//===-- OptionValueSInt64.cpp -----------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Interpreter/OptionValueSInt64.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
2015-01-16 04:08:35 +08:00
#include "lldb/Host/StringConvert.h"
Move classes from Core -> Utility. This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2017-02-03 05:39:50 +08:00
#include "lldb/Utility/Stream.h"
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +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
void OptionValueSInt64::DumpValue(const ExecutionContext *exe_ctx, Stream &strm,
uint32_t dump_mask) {
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// printf ("%p: DumpValue (exe_ctx=%p, strm, mask) m_current_value = %"
// PRIi64
*** 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
// "\n", this, exe_ctx, m_current_value);
if (dump_mask & eDumpOptionType)
strm.Printf("(%s)", GetTypeAsCString());
// if (dump_mask & eDumpOptionName)
// DumpQualifiedName (strm);
if (dump_mask & eDumpOptionValue) {
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
if (dump_mask & eDumpOptionType)
*** 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
strm.PutCString(" = ");
strm.Printf("%" PRIi64, m_current_value);
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
}
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 12:51:55 +08:00
Status OptionValueSInt64::SetValueFromString(llvm::StringRef value_ref,
VarSetOperationType op) {
Status error;
*** 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
switch (op) {
case eVarSetOperationClear:
Clear();
NotifyValueChanged();
break;
case eVarSetOperationReplace:
case eVarSetOperationAssign: {
bool success = false;
std::string value_str = value_ref.trim().str();
int64_t value = StringConvert::ToSInt64(value_str.c_str(), 0, 0, &success);
if (success) {
if (value >= m_min_value && value <= m_max_value) {
m_value_was_set = true;
m_current_value = value;
NotifyValueChanged();
} else
error.SetErrorStringWithFormat(
"%" PRIi64 " is out of range, valid values must be between %" PRIi64
" and %" PRIi64 ".",
value, m_min_value, m_max_value);
} else {
error.SetErrorStringWithFormat("invalid int64_t string value: '%s'",
value_ref.str().c_str());
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +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
} break;
case eVarSetOperationInsertBefore:
case eVarSetOperationInsertAfter:
case eVarSetOperationRemove:
case eVarSetOperationAppend:
case eVarSetOperationInvalid:
error = OptionValue::SetValueFromString(value_ref, op);
break;
}
return error;
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +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
lldb::OptionValueSP OptionValueSInt64::DeepCopy() const {
return OptionValueSP(new OptionValueSInt64(*this));
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
}