2010-06-09 00:52:24 +08:00
|
|
|
//===-- CommandObjectSettings.cpp -------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CommandObjectSettings.h"
|
|
|
|
|
|
|
|
// C Includes
|
|
|
|
// C++ Includes
|
|
|
|
// Other libraries and framework includes
|
2016-02-24 10:05:55 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
// Project includes
|
2017-03-23 07:33:16 +08:00
|
|
|
#include "lldb/Host/OptionParser.h"
|
2016-09-07 04:57:50 +08:00
|
|
|
#include "lldb/Interpreter/CommandCompletions.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
|
|
|
#include "lldb/Interpreter/CommandReturnObject.h"
|
2015-03-04 09:58:01 +08:00
|
|
|
#include "lldb/Interpreter/OptionValueProperties.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
// CommandObjectSettingsSet
|
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
Convert option tables to ArrayRefs.
This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
2016-09-23 04:22:55 +08:00
|
|
|
static OptionDefinition g_settings_set_options[] = {
|
|
|
|
// clang-format off
|
|
|
|
{ LLDB_OPT_SET_2, false, "global", 'g', OptionParser::eNoArgument, nullptr, nullptr, 0, eArgTypeNone, "Apply the new value to the global default value." }
|
|
|
|
// clang-format on
|
|
|
|
};
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsSet : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandObjectSettingsSet(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectRaw(interpreter, "settings set",
|
2016-10-06 05:14:38 +08:00
|
|
|
"Set the value of the specified debugger setting."),
|
2016-09-07 04:57:50 +08:00
|
|
|
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"(
|
2015-07-14 13:48:36 +08:00
|
|
|
|
|
|
|
(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'
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
)"
|
|
|
|
"Warning: The 'set' command re-sets the entire array or dictionary. If you \
|
2015-07-14 13:48:36 +08:00
|
|
|
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, \
|
2016-09-07 04:57:50 +08:00
|
|
|
insert-before or insert-after.");
|
|
|
|
}
|
2010-12-10 08:26:54 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
~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;
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
|
|
|
|
ExecutionContext *execution_context) override {
|
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
const int short_option = m_getopt_table[option_idx].val;
|
2012-01-20 03:22:41 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
switch (short_option) {
|
|
|
|
case 'g':
|
|
|
|
m_global = true;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
error.SetErrorStringWithFormat("unrecognized options '%c'",
|
|
|
|
short_option);
|
|
|
|
break;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return error;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void OptionParsingStarting(ExecutionContext *execution_context) override {
|
|
|
|
m_global = false;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
Convert option tables to ArrayRefs.
This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
2016-09-23 04:22:55 +08:00
|
|
|
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
|
2016-09-23 05:06:13 +08:00
|
|
|
return llvm::makeArrayRef(g_settings_set_options);
|
Convert option tables to ArrayRefs.
This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
2016-09-23 04:22:55 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
// Instance variables to hold the values for command options.
|
|
|
|
|
|
|
|
bool m_global;
|
|
|
|
};
|
|
|
|
|
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();
|
2016-09-07 04:57:50 +08:00
|
|
|
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);
|
2016-09-07 04:57:50 +08:00
|
|
|
++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);
|
2016-09-07 04:57:50 +08:00
|
|
|
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) {
|
2016-09-07 04:57:50 +08:00
|
|
|
// Attempting to complete setting variable name
|
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2016-09-07 04:57:50 +08:00
|
|
|
} 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());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
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);
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::OptionValueSP value_sp(
|
|
|
|
m_interpreter.GetDebugger().GetPropertyValue(
|
|
|
|
&m_exe_ctx, setting_var_name, false, error));
|
|
|
|
if (value_sp) {
|
2018-07-14 02:28:14 +08:00
|
|
|
value_sp->AutoComplete(m_interpreter, request);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2018-07-13 06:28:52 +08:00
|
|
|
bool DoExecute(llvm::StringRef command,
|
|
|
|
CommandReturnObject &result) override {
|
2016-09-07 04:57:50 +08:00
|
|
|
Args cmd_args(command);
|
|
|
|
|
|
|
|
// Process possible options.
|
|
|
|
if (!ParseOptions(cmd_args, result))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
|
|
|
if ((argc < 2) && (!m_options.m_global)) {
|
|
|
|
result.AppendError("'settings set' takes more arguments");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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);
|
2012-08-23 01:17:09 +08:00
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
if (m_options.m_global) {
|
|
|
|
error = m_interpreter.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
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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
|
2016-09-07 04:57:50 +08:00
|
|
|
// if we did not clear the command's exe_ctx first
|
|
|
|
ExecutionContext exe_ctx(m_exe_ctx);
|
|
|
|
m_exe_ctx.Clear();
|
|
|
|
error = m_interpreter.GetDebugger().SetPropertyValue(
|
|
|
|
&exe_ctx, eVarSetOperationAssign, var_name, var_value_cstr);
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
} else {
|
|
|
|
result.SetStatus(eReturnStatusSuccessFinishResult);
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-02-24 10:05:55 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return result.Succeeded();
|
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
private:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandOptions m_options;
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingsShow -- Show current values
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsShow : public CommandObjectParsed {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
|
|
|
protected:
|
2016-09-07 04:57:50 +08:00
|
|
|
bool DoExecute(Args &args, CommandReturnObject &result) override {
|
|
|
|
result.SetStatus(eReturnStatusSuccessFinishResult);
|
|
|
|
|
2016-10-06 07:40:23 +08:00
|
|
|
if (!args.empty()) {
|
2016-11-23 01:10:15 +08:00
|
|
|
for (const auto &arg : args) {
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().DumpPropertyValue(
|
2016-11-23 01:10:15 +08:00
|
|
|
&m_exe_ctx, result.GetOutputStream(), arg.ref,
|
2016-09-07 04:57:50 +08:00
|
|
|
OptionValue::eDumpGroupValue));
|
|
|
|
if (error.Success()) {
|
|
|
|
result.GetOutputStream().EOL();
|
|
|
|
} else {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
m_interpreter.GetDebugger().DumpAllPropertyValues(
|
|
|
|
&m_exe_ctx, result.GetOutputStream(), OptionValue::eDumpGroupValue);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-15 14:56:39 +08:00
|
|
|
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingsList -- List settable variables
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsList : public CommandObjectParsed {
|
2016-07-15 06:03:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
|
2016-10-06 07:40:23 +08:00
|
|
|
// TODO: Convert to StringRef based enumeration. Requires converting
|
|
|
|
// GetPropertyAtPath first.
|
2016-09-07 04:57:50 +08:00
|
|
|
for (size_t i = 0; i < argc; ++i) {
|
|
|
|
const char *property_path = args.GetArgumentAtIndex(i);
|
|
|
|
|
|
|
|
const Property *property =
|
|
|
|
m_interpreter.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);
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
m_interpreter.GetDebugger().DumpAllDescriptions(m_interpreter,
|
|
|
|
result.GetOutputStream());
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
// CommandObjectSettingsRemove
|
|
|
|
//-------------------------------------------------------------------------
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsRemove : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandObjectSettingsRemove(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectRaw(interpreter, "settings remove",
|
|
|
|
"Remove a value from a setting, specified by array "
|
2016-10-06 05:14:38 +08:00
|
|
|
"index or dictionary key.") {
|
2016-09-07 04:57:50 +08:00
|
|
|
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)
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
2018-07-13 06:28:52 +08:00
|
|
|
bool DoExecute(llvm::StringRef command,
|
|
|
|
CommandReturnObject &result) override {
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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);
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().SetPropertyValue(
|
2016-09-07 04:57:50 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationRemove, var_name, var_value_cstr));
|
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
|
|
|
//-------------------------------------------------------------------------
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingsReplace
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsReplace : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandObjectSettingsReplace(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectRaw(interpreter, "settings replace",
|
|
|
|
"Replace the debugger setting value specified by "
|
2016-10-06 05:14:38 +08:00
|
|
|
"array index or dictionary key.") {
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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)
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2018-07-13 06:28:52 +08:00
|
|
|
bool DoExecute(llvm::StringRef command,
|
|
|
|
CommandReturnObject &result) override {
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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);
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().SetPropertyValue(
|
2016-09-07 04:57:50 +08:00
|
|
|
&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);
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
|
|
|
//-------------------------------------------------------------------------
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingsInsertBefore
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsInsertBefore : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandObjectSettingsInsertBefore(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectRaw(interpreter, "settings insert-before",
|
|
|
|
"Insert one or more values into an debugger array "
|
|
|
|
"setting immediately before the specified element "
|
2016-10-06 05:14:38 +08:00
|
|
|
"index.") {
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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)
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2018-07-13 06:28:52 +08:00
|
|
|
bool DoExecute(llvm::StringRef command,
|
|
|
|
CommandReturnObject &result) override {
|
2016-09-07 04:57:50 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Args cmd_args(command);
|
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (argc < 3) {
|
|
|
|
result.AppendError("'settings insert-before' takes more arguments");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
// 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);
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().SetPropertyValue(
|
2016-09-07 04:57:50 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationInsertBefore, var_name, var_value_cstr));
|
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
|
|
|
//-------------------------------------------------------------------------
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingInsertAfter
|
2010-09-04 08:03:46 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsInsertAfter : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandObjectSettingsInsertAfter(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectRaw(interpreter, "settings insert-after",
|
|
|
|
"Insert one or more values into a debugger array "
|
2016-10-06 05:14:38 +08:00
|
|
|
"settings after the specified element index.") {
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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)
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
|
|
|
protected:
|
2018-07-13 06:28:52 +08:00
|
|
|
bool DoExecute(llvm::StringRef command,
|
|
|
|
CommandReturnObject &result) override {
|
2016-09-07 04:57:50 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2010-10-05 06:28:36 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Args cmd_args(command);
|
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2010-10-05 06:28:36 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (argc < 3) {
|
|
|
|
result.AppendError("'settings insert-after' takes more arguments");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
// 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);
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().SetPropertyValue(
|
2016-09-07 04:57:50 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationInsertAfter, var_name, var_value_cstr));
|
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
// CommandObjectSettingsAppend
|
|
|
|
//-------------------------------------------------------------------------
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsAppend : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandObjectSettingsAppend(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectRaw(interpreter, "settings append",
|
|
|
|
"Append one or more values to a debugger array, "
|
2016-10-06 05:14:38 +08:00
|
|
|
"dictionary, or string setting.") {
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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)
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
|
|
|
protected:
|
2018-07-13 06:28:52 +08:00
|
|
|
bool DoExecute(llvm::StringRef command,
|
|
|
|
CommandReturnObject &result) override {
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Do not perform cmd_args.Shift() since StringRef is manipulating the raw
|
|
|
|
// character string later on.
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
// 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);
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().SetPropertyValue(
|
2016-09-07 04:57:50 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationAppend, var_name, var_value_cstr));
|
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
// CommandObjectSettingsClear
|
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
class CommandObjectSettingsClear : public CommandObjectParsed {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-09-07 04:57:50 +08:00
|
|
|
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 {
|
2016-09-07 04:57:50 +08:00
|
|
|
// 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)
|
2016-09-07 04:57:50 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
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
|
|
|
return request.GetMatches().GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error(m_interpreter.GetDebugger().SetPropertyValue(
|
2016-11-18 02:08:12 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationClear, var_name, llvm::StringRef()));
|
2016-09-07 04:57:50 +08:00
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
// CommandObjectMultiwordSettings
|
|
|
|
//-------------------------------------------------------------------------
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
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)));
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
CommandObjectMultiwordSettings::~CommandObjectMultiwordSettings() = default;
|