- move alias help generation to CommandAlias, out of CommandInterpreter
- make alias creation use argument strings instead of OptionArgVectorSP; the former is a more reasonable currency than the latter
- remove m_is_alias from CommandObject, it wasn't actually being used
llvm-svn: 262912
Right now, obviously, this is just the pair of (CommandObjectSP,OptionArgVectorSP), so NFC
This is step one of a larger - and tricky - refactoring which will turn command aliases into interesting objects instead of passive storage that the command interpreter does smart things to
This refactoring, in turn, will allow us to do interesting things with aliases, such as intelligent and customizable help
llvm-svn: 262900
This is useful in cases such as, e.g.
(lldb) help NSString
(the user meant type lookup)
or
(lldb) help kill
(the user is looking for process kill)
Fixes rdar://24868537
llvm-svn: 262271
Summary:
This removes all uses of virtual on functions
where override could be used, including on destructors.
It also adds override where virtual was previously
missing.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13503
llvm-svn: 249564
Existing commands supplying this type of help content have been reworked to take advantage of the changes. In addition to formatting changes, content was changes for accuracy and clarity purposes.
<rdar://problem/21269977>
llvm-svn: 242122
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())
Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones
llvm-svn: 238286
This removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes. To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*. Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.
Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type. For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes
The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.
llvm-svn: 232534
This works by creating a command backed by a class whose interface should - at least - include
def __init__(self, debugger, session_dict)
def __call__(self, args, return_obj, exe_ctx)
What works:
- adding a command via command script add --class
- calling a thusly created command
What is missing:
- support for custom help
- test cases
The missing parts will follow over the next couple of days
This is an improvement over the existing system as:
a) it provides an obvious location for commands to provide help strings (i.e. methods)
b) it allows commands to store state in an obvious fashion
c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-)
llvm-svn: 232136
This new command will delete user defined regular commands, but not aliases. We still have "command unalias" to remove aliases as they are currently in different buckets. Appropriate error messages are displayed to inform the user when "command unalias" is used on removable user defined commands that points users to the "command delete" command.
Added a test to verify we can remove user defined commands and also verify that "command unalias" fails when used on a user defined command.
<rdar://problem/18248300>
llvm-svn: 225535
Fixed the prompt to not include non-printable characters as it was hosing up the prompt when you ran "command regex foo" and entered multi-line editing mode.
Fixed error strings to include more complete descriptions when bad regular expressions are entered.
Removed the old IOHandlerLinesUpdated function as it is no longer needed (inheriting from IOHandlerDelegateMultiline takes care of what this function used to do).
llvm-svn: 222207
Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements
llvm-svn: 222163
do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class. Also expose that to the SB API's.
Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.
I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.
llvm-svn: 219553