[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][Python] Silence GCC warning for modules error workaround

```
lldb-python.h:16:30: warning: ‘g_fcxx_modules_workaround’ defined but not used [-Wunused-variable]
16 | static llvm::Expected<b

[lldb][Python] Silence GCC warning for modules error workaround

```
lldb-python.h:16:30: warning: ‘g_fcxx_modules_workaround’ defined but not used [-Wunused-variable]
16 | static llvm::Expected<bool> *g_fcxx_modules_workaround;
|
```

Workaround originally added in 36cb29cbbe1b22dcd298ad65e1fabe899b7d7249.

show more ...

Work around a module build failure on the bots.

This patch works around what looks like a bug in Clang itself.

The error on the bot is:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40

Work around a module build failure on the bots.

This patch works around what looks like a bug in Clang itself.

The error on the bot is:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40466/consoleText

In module 'LLVM_Utils' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h:18:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: error: 'llvm::Expected<bool>::(anonymous)' from module 'LLVM_Utils.Support.Error' is not present in definition of 'llvm::Expected<bool>' in module 'LLVM_Utils.Support.Error'
union {
^
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
1 error generated.

The intention is to revert this as soon as a proper fix has been identified!

rdar://87845391

show more ...

[lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON

This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

Differential revision: https://reviews.llv

[lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON

This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

Differential revision: https://reviews.llvm.org/D71482

show more ...

[lldb/Host] Use Host/Config.h entries instead of a global define.

As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A g

[lldb/Host] Use Host/Config.h entries instead of a global define.

As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..

Differential revision: https://reviews.llvm.org/D71280

show more ...

[Python] Remove Python include from ScriptInterpreterPython.h

This patch limits the scope of the python header to the implementation
of the python script interpreter plugin. ScriptInterpreterPython

[Python] Remove Python include from ScriptInterpreterPython.h

This patch limits the scope of the python header to the implementation
of the python script interpreter plugin. ScriptInterpreterPython is now
an abstract interface that doesn't expose any Python specific types, and
is implemented by the ScriptInterpreterPythonImpl.

Differential revision: https://reviews.llvm.org/D59976

llvm-svn: 357307

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 ...

Partially revert r335236

Jim pointed out that XCode has build configurations that build without
python and removing the ifdefs around the python code breaks them.

This reverts the #ifdef part of th

Partially revert r335236

Jim pointed out that XCode has build configurations that build without
python and removing the ifdefs around the python code breaks them.

This reverts the #ifdef part of the above patch, while keeping the cmake
parts.

llvm-svn: 335260

show more ...

ScriptInterpreterPython cleanup

Instead of #ifdef-ing the contents of all files in the plugin for all
non-python builds, just disable the plugin at the cmake level. Also,
remove spurious extra linki

ScriptInterpreterPython cleanup

Instead of #ifdef-ing the contents of all files in the plugin for all
non-python builds, just disable the plugin at the cmake level. Also,
remove spurious extra linking of the Python plugin in liblldb. This
plugin is already included as a part of LLDB_ALL_PLUGINS variable.

llvm-svn: 335236

show more ...

s/LLVM_ON_WIN32/_WIN32/, lldb

LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleL

s/LLVM_ON_WIN32/_WIN32/, lldb

LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.

See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.

llvm-svn: 329697

show more ...

Make lldb -Werror clean on Windows.

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

llvm-svn: 283344

*** 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 ...

Delete Host/windows/win32.h

It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you furth

Delete Host/windows/win32.h

It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.

This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.

There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.

This patch depends on LLVM revision r278170.

llvm-svn: 278177

show more ...

Convert the ScriptInterpreter system to a plugin-based one.

Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a spe

Convert the ScriptInterpreter system to a plugin-based one.

Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.

This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.

Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.

Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton

llvm-svn: 243681

show more ...