This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts,
as recommended by the [unittest release
notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3).

For example, `assertTrue(a == b)` is replaced with `assertEqual(a, b)`.
This produces better error messages, e.g. `error: unexpectedly found 1
and 2 to be different` instead of `error: False`.

This was just a thinko. The API StackFrame::GetVariableList takes a
bool for "get_file_globals" which if true will also find file statics
and file globals. But we only were passing that as true if the
ValueType was eValueTypeVariableGlobal, which meant that we never find
file statics. It's okay if we cast too wide a net when we do
GetVariableList as later on we check against the ValueType to filter
globals from statics.

There was a test that had a whole bunch of globals and tested
FindValue on all of them, but had no statics. So I just made one of
the globals a file static, which verifies the fix.

Differential Revision: https://reviews.llvm.org/D151392

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 patch tries to address an interoperability issue when writing
python string into the process memory.

Since the python string is not null-terminated, it would still be
written to memory however, when trying to read it again with
`SBProcess::ReadCStringFromMemory`, the memory read would fail, since
the read string doens't contain a null-terminator, and therefore is not
a valid C string.

To address that, this patch extends the `SBProcess` SWIG interface to
expose a new `WriteMemoryAsCString` method that is only exposed to the
SWIG target language. That method checks that the buffer to write is
null-terminated and otherwise, it appends a null byte at the end of it.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

The sanitizer bots are failing with this test; they
impose a maximum 0x10000000000 size on allocations, and
malloc on darwin will let me malloc that much.  The
alternative to keep this would be to break it out into a
seperate test in TestProcessAIP and skip that if it's on
the sanitizer, but this is seeming too fragile IMO so I'm
punting it entirely.

I'm still getting linux CI bot failures for this test.  It's not
critical, and it depends on a failure mode that is true on Darwin
but I was always gambling that it might fail in the same way on
other systems.

I hardcoded nearly a UINT64_MAX number in this test case,
and python is not able to convert it to a long on some
platforms.  Use sys.maxsize instead; this also would have
failed if the testsuite was run on a 32-bit system.

Add a check for a null destination buffer in SBProcess::ReadMemory,
and return an error if that happens.  If a Python SB API script
tries to allocate a huge amount of memory, the malloc done by the
intermediate layers will fail and will hand a null pointer to
ReadMemory.  lldb will eventually crash trying to write in to that
buffer.

Also add a test that tries to allocate an impossibly large amount
of memory, and hopefully should result in a failed malloc and hitting
this error codepath.

Differential Revision: https://reviews.llvm.org/D143012
rdar://104846609

This patch introduces a new `GetScriptedImplementation` method to the
SBProcess class in the SBAPI. It will allow users of Scripted Processes to
fetch the scripted implementation object from to script interpreter to be
able to interact with it directly (without having to go through lldb).

This allows to user to perform action that are not specified in the
scripted process interface, like calling un-specified methods, but also
to enrich the implementation, by passing it complex objects.

Differential Revision: https://reviews.llvm.org/D143236

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/D131761