gdb: return true in TuiWindow.is_valid only if TUI is enabled

If the user implements a TUI window in Python, and this window
responds to GDB events and then redraws its window contents then there
is currently an edge case which can lead to problems.

The Python API documentation suggests that calling methods like erase
or write on a TUI window (from Python code) will raise an exception if
the window is not valid.

And the description for is_valid says:

  This method returns True when this window is valid. When the user
  changes the TUI layout, windows no longer visible in the new layout
  will be destroyed. At this point, the gdb.TuiWindow will no longer
  be valid, and methods (and attributes) other than is_valid will
  throw an exception.

From this I, as a user, would expect that if I did 'tui disable' to
switch back to CLI mode, then the window would no longer be valid.
However, this is not the case.

When the TUI is disabled the windows in the TUI are not deleted, they
are simply hidden.  As such, currently, the is_valid method continues
to return true.

This means that if the users Python code does something like:

  def event_handler (e):
    global tui_window_object
    if tui_window_object->is_valid ():
      tui_window_object->erase ()
      tui_window_object->write ("Hello World")
  gdb.events.stop.connect (event_handler)

Then when a stop event arrives GDB will try to draw the TUI window,
even when the TUI is disabled.

This exposes two bugs.  First, is_valid should be returning false in
this case, second, if the user forgot to add the is_valid call, then I
believe the erase and write calls should be throwing an
exception (when the TUI is disabled).

The solution to both of these issues is I think bound together, as it
depends on having a working 'is_valid' check.

There's a rogue assert added into tui-layout.c as part of this
commit.  While working on this commit I managed to break GDB such that
TUI_CMD_WIN was nullptr, this was causing GDB to abort.  I'm leaving
the assert in as it might help people catch issues in the future.

This patch is inspired by the work done here:

  https://sourceware.org/pipermail/gdb-patches/2020-December/174338.html

gdb/ChangeLog:

	* python/py-tui.c (gdbpy_tui_window) <is_valid>: New member
	function.
	(REQUIRE_WINDOW): Call is_valid member function.
	(REQUIRE_WINDOW_FOR_SETTER): New define.
	(gdbpy_tui_is_valid): Call is_valid member function.
	(gdbpy_tui_set_title): Call REQUIRE_WINDOW_FOR_SETTER instead.
	* tui/tui-data.h (struct tui_win_info) <is_visible>: Check
	tui_active too.
	* tui/tui-layout.c (tui_apply_current_layout): Add an assert.
	* tui/tui.c (tui_enable): Move setting of tui_active earlier in
	the function.

gdb/doc/ChangeLog:

	* python.texinfo (TUI Windows In Python): Extend description of
	TuiWindow.is_valid.

gdb/testsuite/ChangeLog:

	* gdb.python/tui-window-disabled.c: New file.
	* gdb.python/tui-window-disabled.exp: New file.
	* gdb.python/tui-window-disabled.py: New file.

1 files changed, 5 insertions, 0 deletions

diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 1a5209a..ba3d2f9 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -5848,6 +5848,11 @@ user changes the TUI layout, windows no longer visible in the new
 layout will be destroyed.  At this point, the @code{gdb.TuiWindow}
 will no longer be valid, and methods (and attributes) other than
 @code{is_valid} will throw an exception.
+
+When the TUI is disabled using @code{tui disable} (@pxref{TUI
+Commands,,tui disable}) the window is hidden rather than destroyed,
+but @code{is_valid} will still return @code{False} and other methods
+(and attributes) will still throw an exception.
 @end defun
 
 @defvar TuiWindow.width