llvm-project/lldb/source/Commands/CommandObjectSettings.cpp

1187 lines
39 KiB
C++
Raw Normal View History

//===-- CommandObjectSettings.cpp -------------------------------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "CommandObjectSettings.h"
#include "llvm/ADT/StringRef.h"
#include "lldb/Host/OptionParser.h"
#include "lldb/Interpreter/CommandCompletions.h"
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/CommandReturnObject.h"
#include "lldb/Interpreter/OptionValueProperties.h"
using namespace lldb;
using namespace lldb_private;
// CommandObjectSettingsSet
static constexpr OptionDefinition g_settings_set_options[] = {
#define LLDB_OPTIONS_settings_set
#include "Options.inc"
};
class CommandObjectSettingsSet : public CommandObjectRaw {
public:
CommandObjectSettingsSet(CommandInterpreter &interpreter)
: CommandObjectRaw(interpreter, "settings set",
"Set the value of the specified debugger setting."),
m_options() {
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentData var_name_arg;
CommandArgumentData value_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Define the first (and only) variant of this arg.
value_arg.arg_type = eArgTypeValue;
value_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg2.push_back(value_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
SetHelpLong(
"\nWhen setting a dictionary or array variable, you can set multiple entries \
at once by giving the values to the set command. For example:"
R"(
(lldb) settings set target.run-args value1 value2 value3
(lldb) settings set target.env-vars MYPATH=~/.:/usr/bin SOME_ENV_VAR=12345
(lldb) settings show target.run-args
[0]: 'value1'
[1]: 'value2'
[3]: 'value3'
(lldb) settings show target.env-vars
'MYPATH=~/.:/usr/bin'
'SOME_ENV_VAR=12345'
)"
"Warning: The 'set' command re-sets the entire array or dictionary. If you \
just want to add, remove or update individual values (or add something to \
the end), use one of the other settings sub-commands: append, replace, \
insert-before or insert-after.");
}
~CommandObjectSettingsSet() override = default;
// Overrides base class's behavior where WantsCompletion =
// !WantsRawCommandString.
bool WantsCompletion() override { return true; }
Options *GetOptions() override { return &m_options; }
class CommandOptions : public Options {
public:
CommandOptions() : Options(), m_global(false) {}
~CommandOptions() override = default;
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
ExecutionContext *execution_context) override {
Status error;
const int short_option = m_getopt_table[option_idx].val;
switch (short_option) {
case 'f':
m_force = true;
break;
case 'g':
m_global = true;
break;
default:
error.SetErrorStringWithFormat("unrecognized options '%c'",
short_option);
break;
}
return error;
}
void OptionParsingStarting(ExecutionContext *execution_context) override {
m_global = false;
m_force = false;
}
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
return llvm::makeArrayRef(g_settings_set_options);
}
// Instance variables to hold the values for command options.
bool m_global;
bool m_force;
};
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
const size_t argc = request.GetParsedLine().GetArgumentCount();
const char *arg = nullptr;
int setting_var_idx;
Move option parsing out of the Args class Summary: The args class is used in plenty of places (a lot of them in the lower lldb layers) for representing a list of arguments, and most of these places don't care about option parsing. Moving the option parsing out of the class removes the largest external dependency (there are a couple more, but these are in static functions), and brings us closer to being able to move it to the Utility module). The new home for these functions is the Options class, which was already used as an argument to the parse calls, so this just inverts the dependency between the two. The functions are themselves are mainly just copied -- the biggest functional change I've made to them is to avoid modifying the input Args argument (getopt likes to permute the argument vector), as it was weird to have another class reorder the entries in Args class. So now the functions don't modify the input arguments, and (for those where it makes sense) return a new Args vector instead. I've also made the addition of a "fake arg0" (required for getopt compatibility) an implementation detail rather than a part of interface. While doing that I noticed that ParseForCompletion function was recording the option indexes in the shuffled vector, but then the consumer was looking up the entries in the unshuffled one. This manifested itself as us not being able to complete "watchpoint set variable foo --" (because getopt would move "foo" to the end). Surprisingly all other completions (e.g. "watchpoint set variable foo --w") were not affected by this. However, I couldn't find a comprehensive test for command argument completion, so I consolidated the existing tests and added a bunch of new ones. Reviewers: davide, jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D43837 llvm-svn: 327110
2018-03-09 18:39:40 +08:00
for (setting_var_idx = 0; setting_var_idx < static_cast<int>(argc);
++setting_var_idx) {
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
arg = request.GetParsedLine().GetArgumentAtIndex(setting_var_idx);
if (arg && arg[0] != '-')
break; // We found our setting variable name index
}
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
if (request.GetCursorIndex() == setting_var_idx) {
// Attempting to complete setting variable name
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
} else {
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
arg =
request.GetParsedLine().GetArgumentAtIndex(request.GetCursorIndex());
if (arg) {
if (arg[0] == '-') {
// Complete option name
} else {
// Complete setting value
const char *setting_var_name =
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
request.GetParsedLine().GetArgumentAtIndex(setting_var_idx);
Status error;
lldb::OptionValueSP value_sp(GetDebugger().GetPropertyValue(
&m_exe_ctx, setting_var_name, false, error));
if (value_sp) {
value_sp->AutoComplete(m_interpreter, request);
}
}
}
}
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(llvm::StringRef command,
CommandReturnObject &result) override {
Args cmd_args(command);
// Process possible options.
if (!ParseOptions(cmd_args, result))
return false;
const size_t min_argc = m_options.m_force ? 1 : 2;
const size_t argc = cmd_args.GetArgumentCount();
if ((argc < min_argc) && (!m_options.m_global)) {
result.AppendError("'settings set' takes more arguments");
result.SetStatus(eReturnStatusFailed);
return false;
}
const char *var_name = cmd_args.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError(
"'settings set' command requires a valid variable name");
result.SetStatus(eReturnStatusFailed);
return false;
}
// A missing value corresponds to clearing the setting when "force" is
// specified.
if (argc == 1 && m_options.m_force) {
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationClear, var_name, llvm::StringRef()));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
}
return result.Succeeded();
}
// Split the raw command into var_name and value pair.
llvm::StringRef raw_str(command);
std::string var_value_string = raw_str.split(var_name).second.str();
const char *var_value_cstr =
Args::StripSpaces(var_value_string, true, false, false);
Status error;
if (m_options.m_global) {
error = GetDebugger().SetPropertyValue(nullptr, eVarSetOperationAssign,
var_name, var_value_cstr);
}
if (error.Success()) {
// FIXME this is the same issue as the one in commands script import
// we could be setting target.load-script-from-symbol-file which would
// cause Python scripts to be loaded, which could run LLDB commands (e.g.
// settings set target.process.python-os-plugin-path) and cause a crash
// if we did not clear the command's exe_ctx first
ExecutionContext exe_ctx(m_exe_ctx);
m_exe_ctx.Clear();
error = GetDebugger().SetPropertyValue(&exe_ctx, eVarSetOperationAssign,
var_name, var_value_cstr);
}
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
} else {
result.SetStatus(eReturnStatusSuccessFinishResult);
}
return result.Succeeded();
}
private:
CommandOptions m_options;
};
// CommandObjectSettingsShow -- Show current values
class CommandObjectSettingsShow : public CommandObjectParsed {
public:
CommandObjectSettingsShow(CommandInterpreter &interpreter)
: CommandObjectParsed(interpreter, "settings show",
"Show matching debugger settings and their current "
"values. Defaults to showing all settings.",
nullptr) {
CommandArgumentEntry arg1;
CommandArgumentData var_name_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatOptional;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
}
~CommandObjectSettingsShow() override = default;
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(Args &args, CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishResult);
if (!args.empty()) {
for (const auto &arg : args) {
Status error(GetDebugger().DumpPropertyValue(
&m_exe_ctx, result.GetOutputStream(), arg.ref,
OptionValue::eDumpGroupValue));
if (error.Success()) {
result.GetOutputStream().EOL();
} else {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
}
}
} else {
GetDebugger().DumpAllPropertyValues(&m_exe_ctx, result.GetOutputStream(),
OptionValue::eDumpGroupValue);
}
return result.Succeeded();
}
};
// CommandObjectSettingsWrite -- Write settings to file
static constexpr OptionDefinition g_settings_write_options[] = {
#define LLDB_OPTIONS_settings_write
#include "Options.inc"
};
class CommandObjectSettingsWrite : public CommandObjectParsed {
public:
CommandObjectSettingsWrite(CommandInterpreter &interpreter)
: CommandObjectParsed(
interpreter, "settings export",
"Write matching debugger settings and their "
"current values to a file that can be read in with "
"\"settings read\". Defaults to writing all settings.",
nullptr),
m_options() {
CommandArgumentEntry arg1;
CommandArgumentData var_name_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatOptional;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
}
~CommandObjectSettingsWrite() override = default;
Options *GetOptions() override { return &m_options; }
class CommandOptions : public Options {
public:
CommandOptions() : Options() {}
~CommandOptions() override = default;
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
ExecutionContext *execution_context) override {
Status error;
const int short_option = m_getopt_table[option_idx].val;
switch (short_option) {
case 'f':
m_filename.assign(option_arg);
break;
case 'a':
m_append = true;
break;
default:
error.SetErrorStringWithFormat("unrecognized option '%c'",
short_option);
break;
}
return error;
}
void OptionParsingStarting(ExecutionContext *execution_context) override {
m_filename.clear();
m_append = false;
}
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
return llvm::makeArrayRef(g_settings_write_options);
}
// Instance variables to hold the values for command options.
std::string m_filename;
bool m_append = false;
};
protected:
bool DoExecute(Args &args, CommandReturnObject &result) override {
FileSpec file_spec(m_options.m_filename);
FileSystem::Instance().Resolve(file_spec);
std::string path(file_spec.GetPath());
uint32_t options = File::OpenOptions::eOpenOptionWrite |
File::OpenOptions::eOpenOptionCanCreate;
if (m_options.m_append)
options |= File::OpenOptions::eOpenOptionAppend;
else
options |= File::OpenOptions::eOpenOptionTruncate;
StreamFile out_file(path.c_str(), options,
lldb::eFilePermissionsFileDefault);
if (!out_file.GetFile().IsValid()) {
result.AppendErrorWithFormat("%s: unable to write to file", path.c_str());
result.SetStatus(eReturnStatusFailed);
return false;
}
// Exporting should not be context sensitive.
ExecutionContext clean_ctx;
if (args.empty()) {
GetDebugger().DumpAllPropertyValues(&clean_ctx, out_file,
OptionValue::eDumpGroupExport);
return result.Succeeded();
}
for (const auto &arg : args) {
Status error(GetDebugger().DumpPropertyValue(
&clean_ctx, out_file, arg.ref, OptionValue::eDumpGroupExport));
if (!error.Success()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
}
}
return result.Succeeded();
}
private:
CommandOptions m_options;
};
// CommandObjectSettingsRead -- Read settings from file
static constexpr OptionDefinition g_settings_read_options[] = {
#define LLDB_OPTIONS_settings_read
#include "Options.inc"
};
class CommandObjectSettingsRead : public CommandObjectParsed {
public:
CommandObjectSettingsRead(CommandInterpreter &interpreter)
: CommandObjectParsed(
interpreter, "settings read",
"Read settings previously saved to a file with \"settings write\".",
nullptr),
m_options() {}
~CommandObjectSettingsRead() override = default;
Options *GetOptions() override { return &m_options; }
class CommandOptions : public Options {
public:
CommandOptions() : Options() {}
~CommandOptions() override = default;
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
ExecutionContext *execution_context) override {
Status error;
const int short_option = m_getopt_table[option_idx].val;
switch (short_option) {
case 'f':
m_filename.assign(option_arg);
break;
default:
error.SetErrorStringWithFormat("unrecognized option '%c'",
short_option);
break;
}
return error;
}
void OptionParsingStarting(ExecutionContext *execution_context) override {
m_filename.clear();
}
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
return llvm::makeArrayRef(g_settings_read_options);
}
// Instance variables to hold the values for command options.
std::string m_filename;
};
protected:
bool DoExecute(Args &command, CommandReturnObject &result) override {
FileSpec file(m_options.m_filename);
FileSystem::Instance().Resolve(file);
ExecutionContext clean_ctx;
CommandInterpreterRunOptions options;
options.SetAddToHistory(false);
options.SetEchoCommands(false);
options.SetPrintResults(true);
options.SetPrintErrors(true);
options.SetStopOnError(false);
m_interpreter.HandleCommandsFromFile(file, &clean_ctx, options, result);
return result.Succeeded();
}
private:
CommandOptions m_options;
};
// CommandObjectSettingsList -- List settable variables
class CommandObjectSettingsList : public CommandObjectParsed {
public:
CommandObjectSettingsList(CommandInterpreter &interpreter)
: CommandObjectParsed(interpreter, "settings list",
"List and describe matching debugger settings. "
"Defaults to all listing all settings.",
nullptr) {
CommandArgumentEntry arg;
CommandArgumentData var_name_arg;
CommandArgumentData prefix_name_arg;
// Define the first variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatOptional;
// Define the second variant of this arg.
prefix_name_arg.arg_type = eArgTypeSettingPrefix;
prefix_name_arg.arg_repetition = eArgRepeatOptional;
arg.push_back(var_name_arg);
arg.push_back(prefix_name_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg);
}
~CommandObjectSettingsList() override = default;
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(Args &args, CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishResult);
const bool will_modify = false;
const size_t argc = args.GetArgumentCount();
if (argc > 0) {
const bool dump_qualified_name = true;
// TODO: Convert to StringRef based enumeration. Requires converting
// GetPropertyAtPath first.
for (size_t i = 0; i < argc; ++i) {
const char *property_path = args.GetArgumentAtIndex(i);
const Property *property =
GetDebugger().GetValueProperties()->GetPropertyAtPath(
&m_exe_ctx, will_modify, property_path);
if (property) {
property->DumpDescription(m_interpreter, result.GetOutputStream(), 0,
dump_qualified_name);
} else {
result.AppendErrorWithFormat("invalid property path '%s'",
property_path);
result.SetStatus(eReturnStatusFailed);
}
}
} else {
GetDebugger().DumpAllDescriptions(m_interpreter,
result.GetOutputStream());
}
return result.Succeeded();
}
};
// CommandObjectSettingsRemove
class CommandObjectSettingsRemove : public CommandObjectRaw {
public:
CommandObjectSettingsRemove(CommandInterpreter &interpreter)
: CommandObjectRaw(interpreter, "settings remove",
"Remove a value from a setting, specified by array "
"index or dictionary key.") {
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentData var_name_arg;
CommandArgumentData index_arg;
CommandArgumentData key_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Define the first variant of this arg.
index_arg.arg_type = eArgTypeSettingIndex;
index_arg.arg_repetition = eArgRepeatPlain;
// Define the second variant of this arg.
key_arg.arg_type = eArgTypeSettingKey;
key_arg.arg_repetition = eArgRepeatPlain;
// Push both variants into this arg
arg2.push_back(index_arg);
arg2.push_back(key_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
}
~CommandObjectSettingsRemove() override = default;
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
if (request.GetCursorIndex() < 2)
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(llvm::StringRef command,
CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
Args cmd_args(command);
// Process possible options.
if (!ParseOptions(cmd_args, result))
return false;
const size_t argc = cmd_args.GetArgumentCount();
if (argc == 0) {
result.AppendError("'settings set' takes an array or dictionary item, or "
"an array followed by one or more indexes, or a "
"dictionary followed by one or more key names to "
"remove");
result.SetStatus(eReturnStatusFailed);
return false;
}
const char *var_name = cmd_args.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError(
"'settings set' command requires a valid variable name");
result.SetStatus(eReturnStatusFailed);
return false;
}
// Split the raw command into var_name and value pair.
llvm::StringRef raw_str(command);
std::string var_value_string = raw_str.split(var_name).second.str();
const char *var_value_cstr =
Args::StripSpaces(var_value_string, true, true, false);
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationRemove, var_name, var_value_cstr));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
}
return result.Succeeded();
}
};
// CommandObjectSettingsReplace
class CommandObjectSettingsReplace : public CommandObjectRaw {
public:
CommandObjectSettingsReplace(CommandInterpreter &interpreter)
: CommandObjectRaw(interpreter, "settings replace",
"Replace the debugger setting value specified by "
"array index or dictionary key.") {
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentEntry arg3;
CommandArgumentData var_name_arg;
CommandArgumentData index_arg;
CommandArgumentData key_arg;
CommandArgumentData value_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Define the first (variant of this arg.
index_arg.arg_type = eArgTypeSettingIndex;
index_arg.arg_repetition = eArgRepeatPlain;
// Define the second (variant of this arg.
key_arg.arg_type = eArgTypeSettingKey;
key_arg.arg_repetition = eArgRepeatPlain;
// Put both variants into this arg
arg2.push_back(index_arg);
arg2.push_back(key_arg);
// Define the first (and only) variant of this arg.
value_arg.arg_type = eArgTypeValue;
value_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg3.push_back(value_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
m_arguments.push_back(arg3);
}
~CommandObjectSettingsReplace() override = default;
// Overrides base class's behavior where WantsCompletion =
// !WantsRawCommandString.
bool WantsCompletion() override { return true; }
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
// Attempting to complete variable name
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
if (request.GetCursorIndex() < 2)
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(llvm::StringRef command,
CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
Args cmd_args(command);
const char *var_name = cmd_args.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError("'settings replace' command requires a valid variable "
"name; No value supplied");
result.SetStatus(eReturnStatusFailed);
return false;
}
// Split the raw command into var_name, index_value, and value triple.
llvm::StringRef raw_str(command);
std::string var_value_string = raw_str.split(var_name).second.str();
const char *var_value_cstr =
Args::StripSpaces(var_value_string, true, true, false);
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationReplace, var_name, var_value_cstr));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
} else {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
}
return result.Succeeded();
}
};
// CommandObjectSettingsInsertBefore
class CommandObjectSettingsInsertBefore : public CommandObjectRaw {
public:
CommandObjectSettingsInsertBefore(CommandInterpreter &interpreter)
: CommandObjectRaw(interpreter, "settings insert-before",
"Insert one or more values into an debugger array "
"setting immediately before the specified element "
"index.") {
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentEntry arg3;
CommandArgumentData var_name_arg;
CommandArgumentData index_arg;
CommandArgumentData value_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Define the first (variant of this arg.
index_arg.arg_type = eArgTypeSettingIndex;
index_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg2.push_back(index_arg);
// Define the first (and only) variant of this arg.
value_arg.arg_type = eArgTypeValue;
value_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg3.push_back(value_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
m_arguments.push_back(arg3);
}
~CommandObjectSettingsInsertBefore() override = default;
// Overrides base class's behavior where WantsCompletion =
// !WantsRawCommandString.
bool WantsCompletion() override { return true; }
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
// Attempting to complete variable name
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
if (request.GetCursorIndex() < 2)
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(llvm::StringRef command,
CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
Args cmd_args(command);
const size_t argc = cmd_args.GetArgumentCount();
if (argc < 3) {
result.AppendError("'settings insert-before' takes more arguments");
result.SetStatus(eReturnStatusFailed);
return false;
}
const char *var_name = cmd_args.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError("'settings insert-before' command requires a valid "
"variable name; No value supplied");
result.SetStatus(eReturnStatusFailed);
return false;
}
// Split the raw command into var_name, index_value, and value triple.
llvm::StringRef raw_str(command);
std::string var_value_string = raw_str.split(var_name).second.str();
const char *var_value_cstr =
Args::StripSpaces(var_value_string, true, true, false);
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationInsertBefore, var_name, var_value_cstr));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
}
return result.Succeeded();
}
};
// CommandObjectSettingInsertAfter
class CommandObjectSettingsInsertAfter : public CommandObjectRaw {
public:
CommandObjectSettingsInsertAfter(CommandInterpreter &interpreter)
: CommandObjectRaw(interpreter, "settings insert-after",
"Insert one or more values into a debugger array "
"settings after the specified element index.") {
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentEntry arg3;
CommandArgumentData var_name_arg;
CommandArgumentData index_arg;
CommandArgumentData value_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Define the first (variant of this arg.
index_arg.arg_type = eArgTypeSettingIndex;
index_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg2.push_back(index_arg);
// Define the first (and only) variant of this arg.
value_arg.arg_type = eArgTypeValue;
value_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg3.push_back(value_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
m_arguments.push_back(arg3);
}
~CommandObjectSettingsInsertAfter() override = default;
// Overrides base class's behavior where WantsCompletion =
// !WantsRawCommandString.
bool WantsCompletion() override { return true; }
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
// Attempting to complete variable name
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
if (request.GetCursorIndex() < 2)
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(llvm::StringRef command,
CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
Args cmd_args(command);
const size_t argc = cmd_args.GetArgumentCount();
if (argc < 3) {
result.AppendError("'settings insert-after' takes more arguments");
result.SetStatus(eReturnStatusFailed);
return false;
}
const char *var_name = cmd_args.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError("'settings insert-after' command requires a valid "
"variable name; No value supplied");
result.SetStatus(eReturnStatusFailed);
return false;
}
// Split the raw command into var_name, index_value, and value triple.
llvm::StringRef raw_str(command);
std::string var_value_string = raw_str.split(var_name).second.str();
const char *var_value_cstr =
Args::StripSpaces(var_value_string, true, true, false);
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationInsertAfter, var_name, var_value_cstr));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
}
return result.Succeeded();
}
};
// CommandObjectSettingsAppend
class CommandObjectSettingsAppend : public CommandObjectRaw {
public:
CommandObjectSettingsAppend(CommandInterpreter &interpreter)
: CommandObjectRaw(interpreter, "settings append",
"Append one or more values to a debugger array, "
"dictionary, or string setting.") {
CommandArgumentEntry arg1;
CommandArgumentEntry arg2;
CommandArgumentData var_name_arg;
CommandArgumentData value_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg1.push_back(var_name_arg);
// Define the first (and only) variant of this arg.
value_arg.arg_type = eArgTypeValue;
value_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg2.push_back(value_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg1);
m_arguments.push_back(arg2);
}
~CommandObjectSettingsAppend() override = default;
// Overrides base class's behavior where WantsCompletion =
// !WantsRawCommandString.
bool WantsCompletion() override { return true; }
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
// Attempting to complete variable name
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
if (request.GetCursorIndex() < 2)
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(llvm::StringRef command,
CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
Args cmd_args(command);
const size_t argc = cmd_args.GetArgumentCount();
if (argc < 2) {
result.AppendError("'settings append' takes more arguments");
result.SetStatus(eReturnStatusFailed);
return false;
}
const char *var_name = cmd_args.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError("'settings append' command requires a valid variable "
"name; No value supplied");
result.SetStatus(eReturnStatusFailed);
return false;
}
// Do not perform cmd_args.Shift() since StringRef is manipulating the raw
// character string later on.
// Split the raw command into var_name and value pair.
llvm::StringRef raw_str(command);
std::string var_value_string = raw_str.split(var_name).second.str();
const char *var_value_cstr =
Args::StripSpaces(var_value_string, true, true, false);
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationAppend, var_name, var_value_cstr));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
}
return result.Succeeded();
}
};
// CommandObjectSettingsClear
class CommandObjectSettingsClear : public CommandObjectParsed {
public:
CommandObjectSettingsClear(CommandInterpreter &interpreter)
: CommandObjectParsed(
interpreter, "settings clear",
"Clear a debugger setting array, dictionary, or string.", nullptr) {
CommandArgumentEntry arg;
CommandArgumentData var_name_arg;
// Define the first (and only) variant of this arg.
var_name_arg.arg_type = eArgTypeSettingVariableName;
var_name_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the
// argument entry.
arg.push_back(var_name_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back(arg);
}
~CommandObjectSettingsClear() override = default;
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
int HandleArgumentCompletion(
CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
// Attempting to complete variable name
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
if (request.GetCursorIndex() < 2)
CommandCompletions::InvokeCommonCompletionCallbacks(
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
request, nullptr);
Narrow the CompletionRequest API to being append-only. Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
2018-07-28 02:42:46 +08:00
return request.GetNumberOfMatches();
}
protected:
bool DoExecute(Args &command, CommandReturnObject &result) override {
result.SetStatus(eReturnStatusSuccessFinishNoResult);
const size_t argc = command.GetArgumentCount();
if (argc != 1) {
result.AppendError("'settings clear' takes exactly one argument");
result.SetStatus(eReturnStatusFailed);
return false;
}
const char *var_name = command.GetArgumentAtIndex(0);
if ((var_name == nullptr) || (var_name[0] == '\0')) {
result.AppendError("'settings clear' command requires a valid variable "
"name; No value supplied");
result.SetStatus(eReturnStatusFailed);
return false;
}
Status error(GetDebugger().SetPropertyValue(
&m_exe_ctx, eVarSetOperationClear, var_name, llvm::StringRef()));
if (error.Fail()) {
result.AppendError(error.AsCString());
result.SetStatus(eReturnStatusFailed);
return false;
}
return result.Succeeded();
}
};
// CommandObjectMultiwordSettings
CommandObjectMultiwordSettings::CommandObjectMultiwordSettings(
CommandInterpreter &interpreter)
: CommandObjectMultiword(interpreter, "settings",
"Commands for managing LLDB settings.",
"settings <subcommand> [<command-options>]") {
LoadSubCommand("set",
CommandObjectSP(new CommandObjectSettingsSet(interpreter)));
LoadSubCommand("show",
CommandObjectSP(new CommandObjectSettingsShow(interpreter)));
LoadSubCommand("list",
CommandObjectSP(new CommandObjectSettingsList(interpreter)));
LoadSubCommand("remove",
CommandObjectSP(new CommandObjectSettingsRemove(interpreter)));
LoadSubCommand("replace", CommandObjectSP(
new CommandObjectSettingsReplace(interpreter)));
LoadSubCommand(
"insert-before",
CommandObjectSP(new CommandObjectSettingsInsertBefore(interpreter)));
LoadSubCommand(
"insert-after",
CommandObjectSP(new CommandObjectSettingsInsertAfter(interpreter)));
LoadSubCommand("append",
CommandObjectSP(new CommandObjectSettingsAppend(interpreter)));
LoadSubCommand("clear",
CommandObjectSP(new CommandObjectSettingsClear(interpreter)));
LoadSubCommand("write",
CommandObjectSP(new CommandObjectSettingsWrite(interpreter)));
LoadSubCommand("read",
CommandObjectSP(new CommandObjectSettingsRead(interpreter)));
}
CommandObjectMultiwordSettings::~CommandObjectMultiwordSettings() = default;