github-actions[bot] wrote:
<!--LLVM CODE FORMAT COMMENT: {clang-format}-->
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
<details>
<summary>
You can test this locally with the following command:
</summary>
``````````bash
git-clang-format --diff 2c934dc5e1a3ef7b717400f27d6b9ea21f4e20a0
7d2b1ef31e16aeb369c2e45edae01feebfef866b --extensions h,cpp --
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h
lldb/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp
``````````
</details>
<details>
<summary>
View the diff from clang-format here.
</summary>
``````````diff
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index e78e6068de..91b86f7ec9 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -152,13 +152,14 @@ public:
private:
void InitializeThreadsPrivate() {
-// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
-// so there is no way to determine whether the embedded interpreter
-// was already initialized by some external code. `PyEval_ThreadsInitialized`
-// would always return `true` and `PyGILState_Ensure/Release` flow would be
-// executed instead of unlocking GIL with `PyEval_SaveThread`. When
-// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
- // The only case we should go further and acquire the GIL: it is unlocked.
+ // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside
+ // itself, so there is no way to determine whether the embedded interpreter
+ // was already initialized by some external code.
+ // `PyEval_ThreadsInitialized` would always return `true` and
+ // `PyGILState_Ensure/Release` flow would be executed instead of unlocking
+ // GIL with `PyEval_SaveThread`. When an another thread calls
+ // `PyGILState_Ensure` it would get stuck in deadlock. The only case we
+ // should go further and acquire the GIL: it is unlocked.
if (PyGILState_Check())
return;
``````````
</details>
https://github.com/llvm/llvm-project/pull/124735
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
