[all-commits] [llvm/llvm-project] 0a07c9: [lldb/python] Fix dangling Event and CommandReturn...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0a07c9662e67124b00e375aa4a395998d218b220
      https://github.com/llvm/llvm-project/commit/0a07c9662e67124b00e375aa4a395998d218b220
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-01-04 (Tue, 04 Jan 2022)

  Changed paths:
    M lldb/bindings/python/python-swigsafecast.swig
    M lldb/bindings/python/python-wrapper.swig
    M lldb/test/API/commands/command/script/TestCommandScript.py
    M lldb/test/API/commands/command/script/persistence.py

  Log Message:
  -----------
  [lldb/python] Fix dangling Event and CommandReturnObject references

Unlike the rest of our SB objects, SBEvent and SBCommandReturnObject
have the ability to hold non-owning pointers to their non-SB
counterparts. This makes it hard to ensure the SB objects do not become
dangling once their backing object goes away.

While we could make these two objects behave like others, that would
require plubming even more shared pointers through our internal code
(Event objects are mostly prepared for it, CommandReturnObject are not).
Doing so seems unnecessarily disruptive, given that (unlike for some of
the other objects) I don't see any good reason why would someone want to
hold onto these objects after the function terminates.

For that reason, this patch implements a different approach -- the SB
objects will still hold non-owning pointers, but they will be reset to
the empty/default state as soon as the function terminates. This python
code will not crash if the user decides to store these objects -- but
the objects themselves will be useless/empty.

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