[Lldb-commits] [lldb] [lldb] Fix variable access in old SBFrames after inferior function calls (PR #178823)

[via lldb-commits]

github-actions[bot] wrote:

<!--LLVM CODE FORMAT COMMENT: {darker}-->


:warning: Python code formatter, darker found issues in your code. :warning:

<details>
<summary>
You can test this locally with the following command:
</summary>

``````````bash
darker --check --diff -r origin/main...HEAD lldb/test/API/macosx/extended-backtrace-api/TestExtendedBacktraceAPI.py lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
``````````

:warning:
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing `origin/main` to the base branch/commit you want to compare against.
:warning:

</details>

<details>
<summary>
View the diff from darker here.
</summary>

``````````diff
--- functionalities/scripted_frame_provider/TestScriptedFrameProvider.py	2026-02-03 01:43:23.000000 +0000
+++ functionalities/scripted_frame_provider/TestScriptedFrameProvider.py	2026-02-03 01:45:58.164957 +0000
@@ -843,11 +843,13 @@
         # 2. Still work if the frame provider is re-applied
 
         # Get new frames after stepping.
         frame0_after = thread.GetFrameAtIndex(0)
         self.assertIsNotNone(frame0_after)
-        self.assertTrue(frame0_after.IsValid(), "New frame 0 should be valid after step")
+        self.assertTrue(
+            frame0_after.IsValid(), "New frame 0 should be valid after step"
+        )
 
         # The old frame references might or might not be valid depending on whether
         # the frame provider is still active. What's important is that accessing
         # them doesn't crash and handles the situation gracefully.
         # We'll just verify we can call methods on them without crashing.

``````````

</details>


https://github.com/llvm/llvm-project/pull/178823