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