[NFC][Py Reformat] Reformat python files in lldb

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 problem

[NFC][Py Reformat] Reformat python files in lldb

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

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** 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

show more ...

<rdar://problem/12552374> & <rdar://problem/13100674>

The vtable pointer field is not necessarily a pointer and hence cannot be used for validation

llvm-svn: 173947

Replacing reference to radar number with svn revision

llvm-svn: 172641

Greg created a new API on SBProcess to get an ID that is guaranteed to be unique even in situations where underlying platforms would actually duplicate or hardcode PIDs

The Python data formatters us

Greg created a new API on SBProcess to get an ID that is guaranteed to be unique even in situations where underlying platforms would actually duplicate or hardcode PIDs

The Python data formatters use a per-process cache that was previously keying off the PID. Moving that to be based on this new notion of unique ID.

llvm-svn: 172633

show more ...

<rdar://problem/11398693> Making sure we do not attempt to run code on zombie objects when attempting to format them

llvm-svn: 164156

Fix a potential issue where data formatters can get confused over malformed UUIDs

llvm-svn: 164151

Make the objc-runtime work with Python 2.6

llvm-svn: 161111

Fixes for performance to data formatters - Python < 3.0 is much slower when using True/False as compared to 1/0 for logical values. Wexploit this to our advantage. Other minor tweaks

llvm-svn: 157209

Optimizations to the Python ObjC formatters - Benchmarking infrastructure

llvm-svn: 157066

Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing

llvm-svn: 155563

Making the Cocoa formatters comply with the new on-disk layout of the Python resources - This is one of the steps towards making the data formatters work again

llvm-svn: 155526

Logging for data formatters.

llvm-svn: 153878

adding a summary for Objective-C type 'Class'

llvm-svn: 153541

The Cocoa formatters now provide error messages for many of the common things-went-wrong situations. Previously they would say nothing or log failures to the Python console

llvm-svn: 152673

Several performance-oriented changes to the introspecting data formatters:
(a) the SystemParameters object is now passed around to the formatters; doing so enables the formatters to reuse computed v

Several performance-oriented changes to the introspecting data formatters:
(a) the SystemParameters object is now passed around to the formatters; doing so enables the formatters to reuse computed values for things such as pointer-size and endianness
instead of repeatedly computing these on their own
(b) replacing the global ISA cache with a per-process one
(c) providing a per-process types cache where each formatter can store the types it needs to operate, and be sure to find them the next time without recalculating them
this also enables formatters to share types if they agree on a local naming convention
(d) lazy fetching of data from Objective-C runtime data structures
data is fetched as needed and we stop reading as soon as we determine that an ISA is actually garbage

llvm-svn: 152052

show more ...

added a new formatter for CF(Mutable)BitVector
fixed a few potential NULL-pointer derefs in ValueObject
we have a way to provide docstrings for properties we add to the SWIG layer - a few of these pr

added a new formatter for CF(Mutable)BitVector
fixed a few potential NULL-pointer derefs in ValueObject
we have a way to provide docstrings for properties we add to the SWIG layer - a few of these properties have a docstring already, more will come in future commits
added a new bunch of properties to SBData to make it more natural and Python-like to access the data they contain

llvm-svn: 151962

show more ...

1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data
2) providing an updated list of tagg

1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data
2) providing an updated list of tagged pointers values for the objc_runtime module - hopefully this one is final
3) changing ValueObject::DumpValueObject to use an Options class instead of providing a bulky list of parameters to pass around
this change had been laid out previously, but some clients of DumpValueObject() were still using the old prototype and some arguments
were treated in a special way and passed in directly instead of through the Options class
4) providing new GetSummaryAsCString() and GetValueAsCString() calls in ValueObject that are passed a formatter object and a destination string
and fill the string by formatting themselves using the formatter argument instead of the default for the current ValueObject
5) removing the option to have formats and summaries stick to a variable for the current stoppoint
after some debate, we are going with non-sticky: if you say frame variable --format hex foo, the hex format will only be applied to the current command execution and not stick when redisplaying foo
the other option would be full stickiness, which means that foo would be formatted as hex for its whole lifetime
we are open to suggestions on what feels "natural" in this regard

llvm-svn: 151801

show more ...

Fixing a problem with v1 runtime - plus hopefully finalizing the code to check for tagged pointers

llvm-svn: 151753

This commit:
a) adds a Python summary provider for NSDate
b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around
c) provi

This commit:
a) adds a Python summary provider for NSDate
b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around
c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side
d) contains much needed performance improvements:
1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time
2) redundant memory reads in the Python ObjC runtime wrapper are eliminated
3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object
e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure

llvm-svn: 151703

show more ...

Fixing an if condition which was causing issues in detecting the correct runtime version

llvm-svn: 151388

fixing a syntax error with objc_runtime.py

llvm-svn: 151304

This patch provides a set of formatters for most of the commonly used Cocoa classes.
The formatter for NSString is an improved version of the one previously shipped as an example, the others are new

This patch provides a set of formatters for most of the commonly used Cocoa classes.
The formatter for NSString is an improved version of the one previously shipped as an example, the others are new in design and implementation.
A more robust and OO-compliant Objective-C runtime wrapper is provided for runtime versions 1 and 2 on 32 and 64 bit.
The formatters are contained in a category named "AppKit", which is not enabled at startup.

llvm-svn: 151300

show more ...