| Age | Commit message (Collapse) | Author |
|---|
|
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
|
|
This is a follow-up patch to 6f7835f309b9.
As explained previously, when running from an IDE, it can happen that
the IDE imports some lldb scripts by itself. If the user also tries to
import these commands, lldb will show the following message:
```
error: cannot add command: user command exists and force replace not set
```
This message is confusing to the user, because it suggests that the
command import failed and that the execution should stop. However, in
this case, lldb will continue the execution with the command added
previously by the user.
To prevent that, this patch updates every first-party lldb-packaged
custom commands to override commands that were pre-imported in lldb.
Differential Revision: https://reviews.llvm.org/D140293
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
Not needed now that we require python 3.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D131772
|
|
Update examples and docs to demonstrate using `__lldb_init_module` instead of
the idiom that checks for `lldb.debugger` at the top-level.
```
if __name__ == '__main__':
...
elif lldb.debugger:
...
```
Is replaced with:
```
if __name__ == '__main__':
...
def __lldb_init_module(debugger, internal_dict):
...
```
This change is for two reasons. First, it's generally encouraged not to only
use the convenience singletons (`lldb.{debugger,process,target,etc}`)
interactively from the `script` command. Second, there's a bug where
registering a python class as a command (using `command script add -c ...`),
result in the command not being runnable. Note that registering function-backed
commands does not have this bug.
Differential Revision: https://reviews.llvm.org/D117237
|
|
Differential Revision: https://reviews.llvm.org/D83857
|
|
llvm-svn: 358721
|
|
Differential Revision: https://reviews.llvm.org/D59584
llvm-svn: 356995
|
|
Differential Revision: https://reviews.llvm.org/D59580
llvm-svn: 356695
|
|
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
erroring out.
<rdar://problem/21071347>
llvm-svn: 238764
|
|
or more shared libraries.
llvm-svn: 199937
|
|
process allowing a debugger to attach.
llvm-svn: 186194
|
|
llvm-svn: 185028
|
|
match. Also split things up a bit so this can be run as a stand alone script or in lldb.
llvm-svn: 184628
|
|
the number of types found.
llvm-svn: 184389
|
|
The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.
llvm-svn: 184364
|
