2010-06-09 00:52:24 +08:00
|
|
|
//===-- CommandObjectSettings.cpp -------------------------------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-06-09 00:52:24 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CommandObjectSettings.h"
|
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
|
2017-03-23 07:33:16 +08:00
|
|
|
#include "lldb/Host/OptionParser.h"
|
2010-09-04 08:03:46 +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
|
[lldb] Let table gen create command option initializers.
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).
This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).
Also refactoring the related data structures can now be done without changing the hundred of option initializers.
For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```
For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables in separate patches.
Reviewers: JDevlieghere, davide, sgraenitz
Reviewed By: JDevlieghere
Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64365
llvm-svn: 365908
2019-07-12 23:30:55 +08:00
|
|
|
#define LLDB_OPTIONS_settings_set
|
2019-07-16 17:27:02 +08:00
|
|
|
#include "CommandOptions.inc"
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsSet : public CommandObjectRaw {
|
|
|
|
public:
|
2016-07-15 06:03:10 +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-08-12 07:51:28 +08:00
|
|
|
m_options() {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentEntry arg2;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData value_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
value_arg.arg_type = eArgTypeValue;
|
|
|
|
value_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg2.push_back(value_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg1);
|
|
|
|
m_arguments.push_back(arg2);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
SetHelpLong(
|
2015-07-14 13:48:36 +08:00
|
|
|
"\nWhen setting a dictionary or array variable, you can set multiple entries \
|
|
|
|
at once by giving the values to the set command. For example:"
|
|
|
|
R"(
|
|
|
|
|
|
|
|
(lldb) settings set target.run-args value1 value2 value3
|
|
|
|
(lldb) settings set target.env-vars MYPATH=~/.:/usr/bin SOME_ENV_VAR=12345
|
|
|
|
|
|
|
|
(lldb) settings show target.run-args
|
|
|
|
[0]: 'value1'
|
|
|
|
[1]: 'value2'
|
|
|
|
[3]: 'value3'
|
|
|
|
(lldb) settings show target.env-vars
|
|
|
|
'MYPATH=~/.:/usr/bin'
|
|
|
|
'SOME_ENV_VAR=12345'
|
|
|
|
|
|
|
|
)"
|
|
|
|
"Warning: The 'set' command re-sets the entire array or dictionary. If you \
|
|
|
|
just want to add, remove or update individual values (or add something to \
|
|
|
|
the end), use one of the other settings sub-commands: append, replace, \
|
|
|
|
insert-before or insert-after.");
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-12-10 08:26:54 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsSet() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Overrides base class's behavior where WantsCompletion =
|
|
|
|
// !WantsRawCommandString.
|
|
|
|
bool WantsCompletion() override { return true; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-10-08 00:56:17 +08:00
|
|
|
Options *GetOptions() override { return &m_options; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandOptions : public Options {
|
2016-09-07 04:57:50 +08:00
|
|
|
public:
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandOptions() : Options(), m_global(false) {}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~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-02-24 10:05:55 +08:00
|
|
|
const int short_option = m_getopt_table[option_idx].val;
|
2012-01-20 03:22:41 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
switch (short_option) {
|
2018-10-25 06:04:20 +08:00
|
|
|
case 'f':
|
|
|
|
m_force = true;
|
|
|
|
break;
|
2012-06-09 05:56:10 +08:00
|
|
|
case 'g':
|
|
|
|
m_global = true;
|
|
|
|
break;
|
|
|
|
default:
|
2019-08-22 16:08:05 +08:00
|
|
|
llvm_unreachable("Unimplemented option");
|
2015-10-08 00:56:17 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return error;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2016-08-12 07:51:28 +08:00
|
|
|
void OptionParsingStarting(ExecutionContext *execution_context) override {
|
2012-08-23 01:17:09 +08:00
|
|
|
m_global = false;
|
2018-10-25 06:04:20 +08:00
|
|
|
m_force = false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Instance variables to hold the values for command options.
|
2012-08-23 01:17:09 +08:00
|
|
|
bool m_global;
|
2018-10-25 06:04:20 +08:00
|
|
|
bool m_force;
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
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
|
|
|
|
|
|
|
const size_t argc = request.GetParsedLine().GetArgumentCount();
|
2016-02-24 10:05:55 +08:00
|
|
|
const char *arg = nullptr;
|
2019-09-23 17:46:17 +08:00
|
|
|
size_t setting_var_idx;
|
|
|
|
for (setting_var_idx = 0; setting_var_idx < argc; ++setting_var_idx) {
|
Refactoring for for the internal command line completion API (NFC)
Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).
This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.
Some Q&A:
Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.
Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.
Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.
Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).
Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).
Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).
Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.
Reviewers: davide, jingham, labath
Reviewed By: jingham
Subscribers: mgorny, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48796
llvm-svn: 336146
2018-07-03 05:29:56 +08:00
|
|
|
arg = request.GetParsedLine().GetArgumentAtIndex(setting_var_idx);
|
2012-08-23 01:17:09 +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) {
|
2012-08-23 01:17:09 +08:00
|
|
|
// Attempting to complete setting variable name
|
2016-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2019-08-22 17:02:54 +08:00
|
|
|
return;
|
|
|
|
}
|
2019-10-31 06:26:19 +08:00
|
|
|
arg = request.GetParsedLine().GetArgumentAtIndex(request.GetCursorIndex());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-10-31 06:26:19 +08:00
|
|
|
if (!arg)
|
|
|
|
return;
|
2019-08-22 17:02:54 +08:00
|
|
|
|
2019-10-31 06:26:19 +08:00
|
|
|
// Complete option name
|
|
|
|
if (arg[0] != '-')
|
|
|
|
return;
|
2019-08-22 17:02:54 +08:00
|
|
|
|
2019-10-31 06:26:19 +08:00
|
|
|
// Complete setting value
|
|
|
|
const char *setting_var_name =
|
|
|
|
request.GetParsedLine().GetArgumentAtIndex(setting_var_idx);
|
|
|
|
Status error;
|
|
|
|
lldb::OptionValueSP value_sp(GetDebugger().GetPropertyValue(
|
|
|
|
&m_exe_ctx, setting_var_name, false, error));
|
|
|
|
if (!value_sp)
|
|
|
|
return;
|
|
|
|
value_sp->AutoComplete(m_interpreter, request);
|
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 {
|
2012-06-09 05:56:10 +08:00
|
|
|
Args cmd_args(command);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Process possible options.
|
|
|
|
if (!ParseOptions(cmd_args, result))
|
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-10-25 06:04:20 +08:00
|
|
|
const size_t min_argc = m_options.m_force ? 1 : 2;
|
2012-08-23 01:17:09 +08:00
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2018-10-25 06:04:20 +08:00
|
|
|
|
|
|
|
if ((argc < min_argc) && (!m_options.m_global)) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError("'settings set' takes more arguments");
|
2010-09-04 08:03:46 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-06-09 05:56:10 +08:00
|
|
|
return false;
|
2011-04-20 06:32:36 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
|
|
|
const char *var_name = cmd_args.GetArgumentAtIndex(0);
|
2016-02-24 10:05:55 +08:00
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.AppendError(
|
|
|
|
"'settings set' command requires a valid variable name");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
2018-10-25 06:04:20 +08:00
|
|
|
// A missing value corresponds to clearing the setting when "force" is
|
|
|
|
// specified.
|
|
|
|
if (argc == 1 && m_options.m_force) {
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2018-10-25 06:04:20 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationClear, var_name, llvm::StringRef()));
|
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Split the raw command into var_name and value pair.
|
2019-09-06 16:40:31 +08:00
|
|
|
llvm::StringRef var_value(command);
|
|
|
|
var_value = var_value.split(var_name).second.ltrim();
|
2012-08-23 01:17:09 +08:00
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2019-09-06 16:40:31 +08:00
|
|
|
if (m_options.m_global)
|
2019-04-27 14:19:42 +08:00
|
|
|
error = GetDebugger().SetPropertyValue(nullptr, eVarSetOperationAssign,
|
2019-09-06 16:40:31 +08:00
|
|
|
var_name, var_value);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Success()) {
|
|
|
|
// FIXME this is the same issue as the one in commands script import
|
2010-09-04 08:03:46 +08:00
|
|
|
// 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
|
2012-08-23 01:17:09 +08:00
|
|
|
// if we did not clear the command's exe_ctx first
|
2013-05-21 06:29:23 +08:00
|
|
|
ExecutionContext exe_ctx(m_exe_ctx);
|
|
|
|
m_exe_ctx.Clear();
|
2019-04-27 14:19:42 +08:00
|
|
|
error = GetDebugger().SetPropertyValue(&exe_ctx, eVarSetOperationAssign,
|
2019-09-06 16:40:31 +08:00
|
|
|
var_name, var_value);
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
} else {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishResult);
|
|
|
|
}
|
2016-02-24 10:05:55 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
private:
|
|
|
|
CommandOptions m_options;
|
|
|
|
};
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingsShow -- Show current values
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsShow : public CommandObjectParsed {
|
|
|
|
public:
|
2016-07-15 06:03:10 +08:00
|
|
|
CommandObjectSettingsShow(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectParsed(interpreter, "settings show",
|
|
|
|
"Show matching debugger settings and their current "
|
|
|
|
"values. Defaults to showing all settings.",
|
|
|
|
nullptr) {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentData var_name_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatOptional;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg1);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsShow() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2016-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2010-09-15 14:56:39 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
|
|
|
|
protected:
|
2015-10-08 00:56:17 +08:00
|
|
|
bool DoExecute(Args &args, CommandReturnObject &result) override {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishResult);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-10-06 07:40:23 +08:00
|
|
|
if (!args.empty()) {
|
2016-11-23 01:10:15 +08:00
|
|
|
for (const auto &arg : args) {
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().DumpPropertyValue(
|
2019-09-13 19:26:48 +08:00
|
|
|
&m_exe_ctx, result.GetOutputStream(), arg.ref(),
|
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
|
|
|
OptionValue::eDumpGroupValue));
|
2012-08-23 01:17:09 +08:00
|
|
|
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 {
|
2019-04-27 14:19:42 +08:00
|
|
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-15 14:56:39 +08:00
|
|
|
|
2018-10-26 08:00:17 +08:00
|
|
|
// CommandObjectSettingsWrite -- Write settings to file
|
[lldb] Let table gen create command option initializers.
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).
This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).
Also refactoring the related data structures can now be done without changing the hundred of option initializers.
For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```
For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables in separate patches.
Reviewers: JDevlieghere, davide, sgraenitz
Reviewed By: JDevlieghere
Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64365
llvm-svn: 365908
2019-07-12 23:30:55 +08:00
|
|
|
#define LLDB_OPTIONS_settings_write
|
2019-07-16 17:27:02 +08:00
|
|
|
#include "CommandOptions.inc"
|
2018-10-26 08:00:17 +08:00
|
|
|
|
|
|
|
class CommandObjectSettingsWrite : public CommandObjectParsed {
|
|
|
|
public:
|
|
|
|
CommandObjectSettingsWrite(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectParsed(
|
|
|
|
interpreter, "settings export",
|
|
|
|
"Write matching debugger settings and their "
|
|
|
|
"current values to a file that can be read in with "
|
|
|
|
"\"settings read\". Defaults to writing all settings.",
|
|
|
|
nullptr),
|
|
|
|
m_options() {
|
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
|
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatOptional;
|
|
|
|
|
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
|
|
|
|
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg1);
|
|
|
|
}
|
|
|
|
|
|
|
|
~CommandObjectSettingsWrite() override = default;
|
|
|
|
|
|
|
|
Options *GetOptions() override { return &m_options; }
|
|
|
|
|
|
|
|
class CommandOptions : public Options {
|
|
|
|
public:
|
|
|
|
CommandOptions() : Options() {}
|
|
|
|
|
|
|
|
~CommandOptions() override = default;
|
|
|
|
|
|
|
|
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
|
|
|
|
ExecutionContext *execution_context) override {
|
|
|
|
Status error;
|
|
|
|
const int short_option = m_getopt_table[option_idx].val;
|
|
|
|
|
|
|
|
switch (short_option) {
|
|
|
|
case 'f':
|
|
|
|
m_filename.assign(option_arg);
|
|
|
|
break;
|
|
|
|
case 'a':
|
|
|
|
m_append = true;
|
|
|
|
break;
|
|
|
|
default:
|
2019-08-22 16:08:05 +08:00
|
|
|
llvm_unreachable("Unimplemented option");
|
2018-10-26 08:00:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
void OptionParsingStarting(ExecutionContext *execution_context) override {
|
|
|
|
m_filename.clear();
|
|
|
|
m_append = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
|
|
|
|
return llvm::makeArrayRef(g_settings_write_options);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Instance variables to hold the values for command options.
|
|
|
|
std::string m_filename;
|
|
|
|
bool m_append = false;
|
|
|
|
};
|
|
|
|
|
|
|
|
protected:
|
|
|
|
bool DoExecute(Args &args, CommandReturnObject &result) override {
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec file_spec(m_options.m_filename);
|
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
std::string path(file_spec.GetPath());
|
2019-10-15 04:15:34 +08:00
|
|
|
auto options = File::eOpenOptionWrite | File::eOpenOptionCanCreate;
|
2018-10-26 08:00:17 +08:00
|
|
|
if (m_options.m_append)
|
2019-10-15 04:15:34 +08:00
|
|
|
options |= File::eOpenOptionAppend;
|
2018-10-26 08:00:17 +08:00
|
|
|
else
|
2019-10-15 04:15:34 +08:00
|
|
|
options |= File::eOpenOptionTruncate;
|
2018-10-26 08:00:17 +08:00
|
|
|
|
|
|
|
StreamFile out_file(path.c_str(), options,
|
|
|
|
lldb::eFilePermissionsFileDefault);
|
|
|
|
|
|
|
|
if (!out_file.GetFile().IsValid()) {
|
|
|
|
result.AppendErrorWithFormat("%s: unable to write to file", path.c_str());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Exporting should not be context sensitive.
|
|
|
|
ExecutionContext clean_ctx;
|
|
|
|
|
|
|
|
if (args.empty()) {
|
2019-04-27 14:19:42 +08:00
|
|
|
GetDebugger().DumpAllPropertyValues(&clean_ctx, out_file,
|
|
|
|
OptionValue::eDumpGroupExport);
|
2018-10-26 08:00:17 +08:00
|
|
|
return result.Succeeded();
|
|
|
|
}
|
|
|
|
|
|
|
|
for (const auto &arg : args) {
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().DumpPropertyValue(
|
2019-09-13 19:26:48 +08:00
|
|
|
&clean_ctx, out_file, arg.ref(), OptionValue::eDumpGroupExport));
|
2018-10-26 08:00:17 +08:00
|
|
|
if (!error.Success()) {
|
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
CommandOptions m_options;
|
|
|
|
};
|
|
|
|
|
|
|
|
// CommandObjectSettingsRead -- Read settings from file
|
[lldb] Let table gen create command option initializers.
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).
This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).
Also refactoring the related data structures can now be done without changing the hundred of option initializers.
For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```
For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables in separate patches.
Reviewers: JDevlieghere, davide, sgraenitz
Reviewed By: JDevlieghere
Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64365
llvm-svn: 365908
2019-07-12 23:30:55 +08:00
|
|
|
#define LLDB_OPTIONS_settings_read
|
2019-07-16 17:27:02 +08:00
|
|
|
#include "CommandOptions.inc"
|
2018-10-26 08:00:17 +08:00
|
|
|
|
|
|
|
class CommandObjectSettingsRead : public CommandObjectParsed {
|
|
|
|
public:
|
|
|
|
CommandObjectSettingsRead(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectParsed(
|
|
|
|
interpreter, "settings read",
|
|
|
|
"Read settings previously saved to a file with \"settings write\".",
|
|
|
|
nullptr),
|
|
|
|
m_options() {}
|
|
|
|
|
|
|
|
~CommandObjectSettingsRead() override = default;
|
|
|
|
|
|
|
|
Options *GetOptions() override { return &m_options; }
|
|
|
|
|
|
|
|
class CommandOptions : public Options {
|
|
|
|
public:
|
|
|
|
CommandOptions() : Options() {}
|
|
|
|
|
|
|
|
~CommandOptions() override = default;
|
|
|
|
|
|
|
|
Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
|
|
|
|
ExecutionContext *execution_context) override {
|
|
|
|
Status error;
|
|
|
|
const int short_option = m_getopt_table[option_idx].val;
|
|
|
|
|
|
|
|
switch (short_option) {
|
|
|
|
case 'f':
|
|
|
|
m_filename.assign(option_arg);
|
|
|
|
break;
|
|
|
|
default:
|
2019-08-22 16:08:05 +08:00
|
|
|
llvm_unreachable("Unimplemented option");
|
2018-10-26 08:00:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
void OptionParsingStarting(ExecutionContext *execution_context) override {
|
|
|
|
m_filename.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::ArrayRef<OptionDefinition> GetDefinitions() override {
|
|
|
|
return llvm::makeArrayRef(g_settings_read_options);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Instance variables to hold the values for command options.
|
|
|
|
std::string m_filename;
|
|
|
|
};
|
|
|
|
|
|
|
|
protected:
|
|
|
|
bool DoExecute(Args &command, CommandReturnObject &result) override {
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec file(m_options.m_filename);
|
|
|
|
FileSystem::Instance().Resolve(file);
|
2018-10-26 08:00:17 +08:00
|
|
|
ExecutionContext clean_ctx;
|
|
|
|
CommandInterpreterRunOptions options;
|
|
|
|
options.SetAddToHistory(false);
|
|
|
|
options.SetEchoCommands(false);
|
|
|
|
options.SetPrintResults(true);
|
2019-05-08 09:23:47 +08:00
|
|
|
options.SetPrintErrors(true);
|
2018-10-26 08:00:17 +08:00
|
|
|
options.SetStopOnError(false);
|
|
|
|
m_interpreter.HandleCommandsFromFile(file, &clean_ctx, options, result);
|
|
|
|
return result.Succeeded();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
CommandOptions m_options;
|
|
|
|
};
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// CommandObjectSettingsList -- List settable variables
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsList : public CommandObjectParsed {
|
2016-07-15 06:03:10 +08:00
|
|
|
public:
|
|
|
|
CommandObjectSettingsList(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectParsed(interpreter, "settings list",
|
|
|
|
"List and describe matching debugger settings. "
|
|
|
|
"Defaults to all listing all settings.",
|
|
|
|
nullptr) {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData prefix_name_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatOptional;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the second variant of this arg.
|
|
|
|
prefix_name_arg.arg_type = eArgTypeSettingPrefix;
|
|
|
|
prefix_name_arg.arg_repetition = eArgRepeatOptional;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
arg.push_back(var_name_arg);
|
|
|
|
arg.push_back(prefix_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg);
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsList() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2016-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2015-10-08 00:56:17 +08:00
|
|
|
bool DoExecute(Args &args, CommandReturnObject &result) override {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishResult);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
const bool will_modify = false;
|
|
|
|
const size_t argc = args.GetArgumentCount();
|
|
|
|
if (argc > 0) {
|
|
|
|
const bool dump_qualified_name = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-10-06 07:40:23 +08:00
|
|
|
// TODO: Convert to StringRef based enumeration. Requires converting
|
|
|
|
// GetPropertyAtPath first.
|
2016-02-24 10:05:55 +08:00
|
|
|
for (size_t i = 0; i < argc; ++i) {
|
2012-08-23 01:17:09 +08:00
|
|
|
const char *property_path = args.GetArgumentAtIndex(i);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
|
|
|
const Property *property =
|
2019-04-27 14:19:42 +08:00
|
|
|
GetDebugger().GetValueProperties()->GetPropertyAtPath(
|
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
|
|
|
&m_exe_ctx, will_modify, property_path);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
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 {
|
2019-04-27 14:19:42 +08:00
|
|
|
GetDebugger().DumpAllDescriptions(m_interpreter,
|
|
|
|
result.GetOutputStream());
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
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
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
class CommandObjectSettingsRemove : public CommandObjectRaw {
|
2012-06-09 05:56:10 +08:00
|
|
|
public:
|
2016-07-15 06:03:10 +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.") {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentEntry arg2;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData index_arg;
|
|
|
|
CommandArgumentData key_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first variant of this arg.
|
|
|
|
index_arg.arg_type = eArgTypeSettingIndex;
|
|
|
|
index_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the second variant of this arg.
|
|
|
|
key_arg.arg_type = eArgTypeSettingKey;
|
|
|
|
key_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push both variants into this arg
|
|
|
|
arg2.push_back(index_arg);
|
|
|
|
arg2.push_back(key_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg1);
|
|
|
|
m_arguments.push_back(arg2);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
~CommandObjectSettingsRemove() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-08-21 20:57:06 +08:00
|
|
|
bool WantsCompletion() override { return true; }
|
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
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)
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-08-12 07:51:28 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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 {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
Args cmd_args(command);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Process possible options.
|
|
|
|
if (!ParseOptions(cmd_args, result))
|
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2012-08-23 01:17:09 +08:00
|
|
|
if (argc == 0) {
|
2019-08-21 21:24:21 +08:00
|
|
|
result.AppendError("'settings remove' takes an array or dictionary item, "
|
|
|
|
"or an array followed by one or more indexes, or a "
|
2012-06-09 05:56:10 +08:00
|
|
|
"dictionary followed by one or more key names to "
|
|
|
|
"remove");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-08-23 01:17:09 +08:00
|
|
|
return false;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
const char *var_name = cmd_args.GetArgumentAtIndex(0);
|
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
|
|
|
result.AppendError(
|
2019-08-21 21:24:21 +08:00
|
|
|
"'settings remove' command requires a valid variable name");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2015-10-08 00:56:17 +08:00
|
|
|
// Split the raw command into var_name and value pair.
|
2019-09-06 16:40:31 +08:00
|
|
|
llvm::StringRef var_value(command);
|
|
|
|
var_value = var_value.split(var_name).second.trim();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2019-09-06 16:40:31 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationRemove, var_name, var_value));
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsReplace : public CommandObjectRaw {
|
|
|
|
public:
|
2016-07-15 06:03:10 +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.") {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentEntry arg2;
|
|
|
|
CommandArgumentEntry arg3;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData index_arg;
|
|
|
|
CommandArgumentData key_arg;
|
|
|
|
CommandArgumentData value_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (variant of this arg.
|
|
|
|
index_arg.arg_type = eArgTypeSettingIndex;
|
|
|
|
index_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the second (variant of this arg.
|
|
|
|
key_arg.arg_type = eArgTypeSettingKey;
|
|
|
|
key_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Put both variants into this arg
|
|
|
|
arg2.push_back(index_arg);
|
|
|
|
arg2.push_back(key_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
value_arg.arg_type = eArgTypeValue;
|
|
|
|
value_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg3.push_back(value_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// 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);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsReplace() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Overrides base class's behavior where WantsCompletion =
|
|
|
|
// !WantsRawCommandString.
|
2015-10-08 00:56:17 +08:00
|
|
|
bool WantsCompletion() override { return true; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2012-06-09 05:56:10 +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-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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 {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
Args cmd_args(command);
|
|
|
|
const char *var_name = cmd_args.GetArgumentAtIndex(0);
|
2016-02-24 10:05:55 +08:00
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError("'settings replace' command requires a valid variable "
|
2013-03-06 07:52:49 +08:00
|
|
|
"name; No value supplied");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-08-23 01:17:09 +08:00
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Split the raw command into var_name, index_value, and value triple.
|
2019-09-06 16:40:31 +08:00
|
|
|
llvm::StringRef var_value(command);
|
|
|
|
var_value = var_value.split(var_name).second.trim();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2019-09-06 16:40:31 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationReplace, var_name, var_value));
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
} else {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsInsertBefore : public CommandObjectRaw {
|
|
|
|
public:
|
2016-07-15 06:03:10 +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.") {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentEntry arg2;
|
|
|
|
CommandArgumentEntry arg3;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData index_arg;
|
|
|
|
CommandArgumentData value_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (variant of this arg.
|
|
|
|
index_arg.arg_type = eArgTypeSettingIndex;
|
|
|
|
index_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg2.push_back(index_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
value_arg.arg_type = eArgTypeValue;
|
|
|
|
value_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg3.push_back(value_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// 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);
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsInsertBefore() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Overrides base class's behavior where WantsCompletion =
|
|
|
|
// !WantsRawCommandString.
|
2015-10-08 00:56:17 +08:00
|
|
|
bool WantsCompletion() override { return true; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2012-06-09 05:56:10 +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-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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 {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
Args cmd_args(command);
|
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
if (argc < 3) {
|
|
|
|
result.AppendError("'settings insert-before' takes more arguments");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-08-23 01:17:09 +08:00
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *var_name = cmd_args.GetArgumentAtIndex(0);
|
2016-02-24 10:05:55 +08:00
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError("'settings insert-before' command requires a valid "
|
|
|
|
"variable name; No value supplied");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Split the raw command into var_name, index_value, and value triple.
|
2019-09-06 16:40:31 +08:00
|
|
|
llvm::StringRef var_value(command);
|
|
|
|
var_value = var_value.split(var_name).second.trim();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2019-09-06 16:40:31 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationInsertBefore, var_name, var_value));
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsInsertAfter : public CommandObjectRaw {
|
|
|
|
public:
|
2016-07-15 06:03:10 +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.") {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentEntry arg2;
|
|
|
|
CommandArgumentEntry arg3;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData index_arg;
|
|
|
|
CommandArgumentData value_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (variant of this arg.
|
|
|
|
index_arg.arg_type = eArgTypeSettingIndex;
|
|
|
|
index_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg2.push_back(index_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
value_arg.arg_type = eArgTypeValue;
|
|
|
|
value_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg3.push_back(value_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// 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);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
~CommandObjectSettingsInsertAfter() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Overrides base class's behavior where WantsCompletion =
|
|
|
|
// !WantsRawCommandString.
|
|
|
|
bool WantsCompletion() override { return true; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2012-06-09 05:56:10 +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)
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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 {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2010-10-05 06:28:36 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
Args cmd_args(command);
|
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2010-10-05 06:28:36 +08:00
|
|
|
|
2012-08-23 01:17:09 +08:00
|
|
|
if (argc < 3) {
|
|
|
|
result.AppendError("'settings insert-after' takes more arguments");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-08-23 01:17:09 +08:00
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
const char *var_name = cmd_args.GetArgumentAtIndex(0);
|
2016-02-24 10:05:55 +08:00
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
2012-06-09 05:56:10 +08:00
|
|
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Split the raw command into var_name, index_value, and value triple.
|
2019-09-06 16:40:31 +08:00
|
|
|
llvm::StringRef var_value(command);
|
|
|
|
var_value = var_value.split(var_name).second.trim();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2019-09-06 16:40:31 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationInsertAfter, var_name, var_value));
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
|
|
|
result.AppendError(error.AsCString());
|
2010-09-04 08:03:46 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-06-09 05:56:10 +08:00
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// CommandObjectSettingsAppend
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsAppend : public CommandObjectRaw {
|
|
|
|
public:
|
2016-07-15 06:03:10 +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.") {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg1;
|
|
|
|
CommandArgumentEntry arg2;
|
|
|
|
CommandArgumentData var_name_arg;
|
|
|
|
CommandArgumentData value_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg1.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
value_arg.arg_type = eArgTypeValue;
|
|
|
|
value_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg2.push_back(value_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg1);
|
|
|
|
m_arguments.push_back(arg2);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsAppend() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Overrides base class's behavior where WantsCompletion =
|
|
|
|
// !WantsRawCommandString.
|
2015-10-08 00:56:17 +08:00
|
|
|
bool WantsCompletion() override { return true; }
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2012-06-09 05:56:10 +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-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
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 {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
2012-06-09 05:56:10 +08:00
|
|
|
Args cmd_args(command);
|
2012-08-23 01:17:09 +08:00
|
|
|
const size_t argc = cmd_args.GetArgumentCount();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
if (argc < 2) {
|
|
|
|
result.AppendError("'settings append' takes more arguments");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2013-03-06 07:52:49 +08:00
|
|
|
const char *var_name = cmd_args.GetArgumentAtIndex(0);
|
2012-08-23 01:17:09 +08:00
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
|
|
|
result.AppendError("'settings append' command requires a valid variable "
|
|
|
|
"name; No value supplied");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-08-23 01:17:09 +08:00
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
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
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Split the raw command into var_name and value pair.
|
2019-09-06 16:40:31 +08:00
|
|
|
llvm::StringRef var_value(command);
|
|
|
|
var_value = var_value.split(var_name).second.trim();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2019-09-06 16:40:31 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationAppend, var_name, var_value));
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-06-09 05:56:10 +08:00
|
|
|
};
|
2010-09-04 08:03:46 +08:00
|
|
|
|
|
|
|
// CommandObjectSettingsClear
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
class CommandObjectSettingsClear : public CommandObjectParsed {
|
|
|
|
public:
|
2016-07-15 06:03:10 +08:00
|
|
|
CommandObjectSettingsClear(CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectParsed(
|
|
|
|
interpreter, "settings clear",
|
|
|
|
"Clear a debugger setting array, dictionary, or string.", nullptr) {
|
2012-06-09 05:56:10 +08:00
|
|
|
CommandArgumentEntry arg;
|
|
|
|
CommandArgumentData var_name_arg;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Define the first (and only) variant of this arg.
|
|
|
|
var_name_arg.arg_type = eArgTypeSettingVariableName;
|
|
|
|
var_name_arg.arg_repetition = eArgRepeatPlain;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// There is only one variant this argument could be; put it into the
|
|
|
|
// argument entry.
|
|
|
|
arg.push_back(var_name_arg);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
// Push the data for the first argument into the m_arguments vector.
|
|
|
|
m_arguments.push_back(arg);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
~CommandObjectSettingsClear() override = default;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void
|
|
|
|
HandleArgumentCompletion(CompletionRequest &request,
|
|
|
|
OptionElementVector &opt_element_vector) override {
|
2012-06-09 05:56:10 +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-08-12 07:51:28 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
2016-02-24 10:05:55 +08:00
|
|
|
GetCommandInterpreter(), CommandCompletions::eSettingsNameCompletion,
|
2018-07-14 02:28:14 +08:00
|
|
|
request, nullptr);
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
protected:
|
2015-10-08 00:56:17 +08:00
|
|
|
bool DoExecute(Args &command, CommandReturnObject &result) override {
|
2012-08-23 01:17:09 +08:00
|
|
|
result.SetStatus(eReturnStatusSuccessFinishNoResult);
|
|
|
|
const size_t argc = command.GetArgumentCount();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
if (argc != 1) {
|
2014-07-02 05:22:11 +08:00
|
|
|
result.AppendError("'settings clear' takes exactly one argument");
|
2012-06-09 05:56:10 +08:00
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
const char *var_name = command.GetArgumentAtIndex(0);
|
2016-02-24 10:05:55 +08:00
|
|
|
if ((var_name == nullptr) || (var_name[0] == '\0')) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError("'settings clear' command requires a valid variable "
|
|
|
|
"name; No value supplied");
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
2012-08-23 01:17:09 +08:00
|
|
|
return false;
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
2010-09-04 08:03:46 +08:00
|
|
|
|
2019-04-27 14:19:42 +08:00
|
|
|
Status error(GetDebugger().SetPropertyValue(
|
2016-11-18 02:08:12 +08:00
|
|
|
&m_exe_ctx, eVarSetOperationClear, var_name, llvm::StringRef()));
|
2012-08-23 01:17:09 +08:00
|
|
|
if (error.Fail()) {
|
2012-06-09 05:56:10 +08:00
|
|
|
result.AppendError(error.AsCString());
|
|
|
|
result.SetStatus(eReturnStatusFailed);
|
|
|
|
return false;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-06-09 05:56:10 +08:00
|
|
|
return result.Succeeded();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
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-07-15 06:03:10 +08:00
|
|
|
CommandObjectMultiwordSettings::CommandObjectMultiwordSettings(
|
|
|
|
CommandInterpreter &interpreter)
|
|
|
|
: CommandObjectMultiword(interpreter, "settings",
|
|
|
|
"Commands for managing LLDB settings.",
|
|
|
|
"settings <subcommand> [<command-options>]") {
|
2012-06-09 05:56:10 +08:00
|
|
|
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)));
|
2018-10-26 08:00:17 +08:00
|
|
|
LoadSubCommand("write",
|
|
|
|
CommandObjectSP(new CommandObjectSettingsWrite(interpreter)));
|
|
|
|
LoadSubCommand("read",
|
|
|
|
CommandObjectSP(new CommandObjectSettingsRead(interpreter)));
|
2012-06-09 05:56:10 +08:00
|
|
|
}
|
|
|
|
|
2016-02-24 10:05:55 +08:00
|
|
|
CommandObjectMultiwordSettings::~CommandObjectMultiwordSettings() = default;
|