This patch should allow the user to set specific auto-completion type
for their custom commands.
To do so, we had to hoist the `CompletionType` enum so the user can
access it and add a new completion type flag to the CommandScriptAdd
Command Object.
So now, the user can specify which completion type will be used with
their custom command, when they register it.
This also makes the `crashlog` custom commands use disk-file completion
type, to browse through the user file system and load the report.
Differential Revision: https://reviews.llvm.org/D152011
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Modular just announced a new language called Mojo. This patch adds an entry in the language list in LLDB for minimal support (e.g. being able to create a TypeSystem for this language). We will later add debug info entries when the language matures.
This patch adds the following methods:
* `GetType()`
* `GetWatchValueKind()`
* `GetWatchSpec()`
* `IsWatchingReads()`
* `IsWatchingWrites()`
These mostly expose methods that `lldb_private::Watchpoint` already
had. Tests are included that exercise these new methods.
The motivation for exposing these are as follows:
* `GetType()` - With this information and the address from a watchpoint
it is now possible to construct an SBValue from an SBWatchpoint.
Previously this wasn't possible. The included test case illustrates
doing this.
* `GetWatchValueKind()` - This allows the caller to determine whether the
watchpoint is a variable watchpoint or an expression watchpoint. A new
enum (`WatchpointValueKind`) has been introduced to represent the
return values. Unfortunately the name `WatchpointKind` was already
taken.
* `GetWatchSpec()` - This allows (at least for variable watchpoints)
to use a sensible name for SBValues created from an SBWatchpoint.
* `IsWatchingReads()` - This allow checking if a watchpoint is
monitoring read accesses.
* `IsWatchingWRites()` - This allow checking if a watchpoint is
monitoring write accesses.
rdar://105606978
Reviewers: jingham, mib, bulbazord, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D144937
D120690 introduced `eBasicTypeChar8` but missed proper documentation order. This also introduces the missing bindings data on Swig, which should correspond with the documented information.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D116136
Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.
Differential Revision: https://reviews.llvm.org/D100196
Enums and constants are currently missing in the new LLDB Python API docs.
In theory we could just let them be autogenerated like the SB API classes, but sadly the generated documentation
suffers from a bunch of problems. Most of these problems come from the way SWIG is representing enums, which is
done by translating every single enum case into its own constant. This has a bunch of nasty effects:
* Because SWIG throws away the enum types, we can't actually reference the enum type itself in the API. Also because automodapi is impossible to script, this can't be fixed in post (at least without running like sed over the output files).
* The lack of enum types also causes that every enum *case* has its own full doc page. Having a full doc page that just shows a single enum case is pointless and it really slows down sphinx.
* There is no SWIG code for the enums, so there is also no place to write documentation strings for them. Also there is no support for copying the doxygen strings (which would be in the wrong format, but better than nothing) for enums (let alone our defines), so we can't really document all this code.
* Because the enum cases are just forwards to the native lldb module (which we mock), automodapi actually takes the `Mock` docstrings and adds it to every single enum case.
I don't see any way to solve this via automodapi or SWIG. The most reasonable way to solve this is IMHO to write a simple Clang tool
that just parses our enum/constant headers and emits an *.rst file that we check in. This way we can do all the LLDB-specific enum case and constant
grouping that we need to make a readable documentation page.
As we're without any real documentation until I get around to write that tool, I wrote a doc page for the enums/constants as a stop gap measure.
Most of this is done by just grepping our enum header and then manually cleaning up all the artifacts and copying the few doc strings we have.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D94959
