[lldb][NFC] Format part of ScriptInterpreterPython.cpp

Was flagged in https://github.com/llvm/llvm-project/pull/124735
but done separately so it didn't get in the way of that.

[lldb] Make Python >= 3.8 required for LLDB 21 (#124735)

As decided on
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731.

LLDB 20 recommended `>=

[lldb] Make Python >= 3.8 required for LLDB 21 (#124735)

As decided on
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731.

LLDB 20 recommended `>= 3.8` but did not remove support for anything
earlier. Now we are in what will become LLDB 21, so I'm removing that
support and making
`>= 3.8` required.

See https://docs.python.org/3/c-api/apiabiversion.html#c.PY_VERSION_HEX
for the format of PY_VERSION_HEX.

show more ...

[lldb] Use PY_VERSION_HEX to simplify conditional compilation (NFC) (#114346)

Use PY_VERSION_HEX to simplify conditional compilation depending on the
Python version.

This also adds a static_asse

[lldb] Use PY_VERSION_HEX to simplify conditional compilation (NFC) (#114346)

Use PY_VERSION_HEX to simplify conditional compilation depending on the
Python version.

This also adds a static_assert to lldb-python to error out with a
meaningful diagnostic when you try building LLDB with an older Python
version in preparation for [1].

[1]
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731/15

show more ...

[lldb] Fix formatting and whitespace in ScriptInterpreterPython (NFC)

[lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building aga

[lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475

show more ...

Revert "[lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC)" (#114290)

Reverts llvm/llvm-project#114112 because this triggers a compile error:

```
no known conversion from 'str_type' (ak

Revert "[lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC)" (#114290)

Reverts llvm/llvm-project#114112 because this triggers a compile error:

```
no known conversion from 'str_type' (aka 'wchar_t *') to 'const char *' for 3rd argument
221 | PyAPI_FUNC(PyStatus) PyConfig_SetBytesString(
| ^
222 | PyConfig *config,
223 | wchar_t **config_str,
224 | const char *str);
| ~~~~~~~~~~~~~~~
1 error generated.

```

show more ...

[lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building ag

[lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475

show more ...

[lldb] Move ValueObject into its own library (NFC) (#113393)

ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-

[lldb] Move ValueObject into its own library (NFC) (#113393)

ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```

show more ...

Add the ability to define custom completers to the parsed_cmd template. (#109062)

If your arguments or option values are of a type that naturally uses one
of our common completion mechanisms, you w

Add the ability to define custom completers to the parsed_cmd template. (#109062)

If your arguments or option values are of a type that naturally uses one
of our common completion mechanisms, you will get completion for free.
But if you have your own custom values or if you want to do fancy things
like have `break set -s foo.dylib -n ba<TAB>` only complete on symbols
in foo.dylib, you can use this new mechanism to achieve that.

show more ...

[lldb/Interpreter] Introduce ScriptedStopHook{,Python}Interface & make use of it (#109498)

This patch re-lands #105449 and fixes the various test failures.

---------

Signed-off-by: Med Ismail

[lldb/Interpreter] Introduce ScriptedStopHook{,Python}Interface & make use of it (#109498)

This patch re-lands #105449 and fixes the various test failures.

---------

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Revert "[lldb] Fix SWIG wrapper compilation error"

...and "[lldb/Interpreter] Introduce `ScriptedStopHook{,Python}Interface` & make use of it (#105449)"

This reverts commit 76b827bb4d5b4cc4d3229c4c

Revert "[lldb] Fix SWIG wrapper compilation error"

...and "[lldb/Interpreter] Introduce `ScriptedStopHook{,Python}Interface` & make use of it (#105449)"

This reverts commit 76b827bb4d5b4cc4d3229c4c6de2529e8b156810, and commit 1e131ddfa8f1d7b18c85c6e4079458be8b419421
because the first commit caused the test command-stop-hook-output.test to fail.

show more ...

[lldb/Interpreter] Introduce `ScriptedStopHook{,Python}Interface` & make use of it (#105449)

This patch introduces new `ScriptedStopHook{,Python}Interface` classes
that make use of the Scripted Int

[lldb/Interpreter] Introduce `ScriptedStopHook{,Python}Interface` & make use of it (#105449)

This patch introduces new `ScriptedStopHook{,Python}Interface` classes
that make use of the Scripted Interface infrastructure and makes use of
it in `StopHookScripted`.

It also relax the requirement on the number of argument for initializing
scripting extension if the size of the interface parameter pack contains
1 less element than the extension maximum number of positional arguments
for this initializer.
This addresses the cases where the embedded interpreter session
dictionary is passed to the extension initializer which is not used most
of the time.

---------

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163)

…ror() [NFC]

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

Revert "Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)""

This reverts commit 547917aebd1e79a8929b53f0ddf3b5185ee4df74.

Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)"

This reverts commit f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9.

This commit introduces an msan violation. See the dis

Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)"

This reverts commit f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9.

This commit introduces an msan violation. See the discussion on https://github.com/llvm/llvm-project/pull/104523.

show more ...

[lldb] Extend frame recognizers to hide frames from backtraces (#104523)

Compilers and language runtimes often use helper functions that are
fundamentally uninteresting when debugging anything but

[lldb] Extend frame recognizers to hide frames from backtraces (#104523)

Compilers and language runtimes often use helper functions that are
fundamentally uninteresting when debugging anything but the
compiler/runtime itself. This patch introduces a user-extensible
mechanism that allows for these frames to be hidden from backtraces and
automatically skipped over when navigating the stack with `up` and
`down`.

This does not affect the numbering of frames, so `f <N>` will still
provide access to the hidden frames. The `bt` output will also print a
hint that frames have been hidden.

My primary motivation for this feature is to hide thunks in the Swift
programming language, but I'm including an example recognizer for
`std::function::operator()` that I wished for myself many times while
debugging LLDB.

rdar://126629381


Example output. (Yes, my proof-of-concept recognizer could hide even
more frames if we had a method that returned the function name without
the return type or I used something that isn't based off regex, but it's
really only meant as an example).

before:
```
(lldb) thread backtrace --filtered=false
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
frame #3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12
frame #4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10
frame #5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12
frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
frame #8: 0x0000000183cdf154 dyld`start + 2476
(lldb)
```

after

```
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10
frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25
frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12
frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10
frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10
frame #8: 0x0000000183cdf154 dyld`start + 2476
Note: Some frames were hidden by frame recognizers
```

show more ...

[lldb] Fix windows debug build after 9d07f43 (#104896)

This patch tries to fix an issue with the windows debug builds where the
PDB file for python scripted interfaces cannot be opened since its pa

[lldb] Fix windows debug build after 9d07f43 (#104896)

This patch tries to fix an issue with the windows debug builds where the
PDB file for python scripted interfaces cannot be opened since its path
length exceed the windows `MAX_PATH` limit:

https://github.com/llvm/llvm-project/pull/101672#issuecomment-2289481324

This patch addresses the issue by building all the interfaces as a
single library plugin that initiliazes each component as part of its
`Initialize` method, instead of building each interface as its own
library plugin.

This keeps the build artifact path length smaller while respecting the
naming convention and without making any exception in the build system.

Fixes #104895.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Reland "[lldb] Reland 2402b3213c2f with `/H` to debug the windows build issue (#101672)

This reverts commit 9effefbae8d96006a4dd29bb9ab8532fd408559d.

With the include order in ScriptedProcessPyth

Reland "[lldb] Reland 2402b3213c2f with `/H` to debug the windows build issue (#101672)

This reverts commit 9effefbae8d96006a4dd29bb9ab8532fd408559d.

With the include order in ScriptedProcessPythonInterface.cpp fixed
(though I cannot explain exactly why it works) and removes the /H flag
intended for debugging this issue.

I think it is something to do with Process.h pulling in PosixApi.h
somewhere along the line, and including Process.h after lldb-python.h
means that NO_PID_T is defined to prevent a redefinition of pid_t.

show more ...

Revert "[lldb] Reland 2402b3213c2f with `/H` to debug the windows build issue"

This reverts commit e72cdae47b4e263ea97b2bdd75cf44c1510cf3be, which broke
LLVM's lldb builder for Windows msvc.

[lldb] Reland 2402b3213c2f with `/H` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.org/

[lldb] Reland 2402b3213c2f with `/H` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.org/buildbot/#/builders/141/builds/1175/

However this patch adds the `/H` compiler flag when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.

This patch will be revert after 1 failing run on the windows bot.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Revert "[lldb] Reland 2402b3213c2f with `-H` to debug the windows build issue"

This reverts commit c35c4c72e4977258fc1da940e0470e8d0671bf07.

[lldb] Reland 2402b3213c2f with `-H` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.org/

[lldb] Reland 2402b3213c2f with `-H` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.org/buildbot/#/builders/141/builds/1175/

However this patch adds the `-H` compiler flag when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.

This patch will be revert after 1 failing run on the windows bot.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Revert "[lldb] Reland 2402b3213c2f with `-H -MM` to debug the windows build issue"

This reverts commit 6bd5fd35063cd14b0a56bc6f7fb1e7b6e1ac56d5.

[lldb] Reland 2402b3213c2f with `-H -MM` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.

[lldb] Reland 2402b3213c2f with `-H -MM` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.org/buildbot/#/builders/141/builds/1175/

However this patch adds the `-H` & `-MM` compiler flags when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.

This patch will be revert after 1 failing run on the windows bot.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...