Currently, we always pass the "selected" execution context to the statusline. When handling a process or thread event, we can be more precise, and build an execution context from the event data. This PR also adopts the new `StoppedExecutionContext` that was recently introduced.
Terminal resizing continues to be a source of statusline bugs, so much so that some users have started disabling it altogether. Different operating systems and terminal emulators exhibit subtly different behaviors, making it nearly impossible to handle resizing reliably across the board. This patch sidesteps those issues by clearing the entire screen when the terminal is resized. This avoids having to account for the previous, potentially wrapped statusline, the underlying cause of many of the aforementioned bugs. The obvious downside is that this clears the on-screen history, but I believe that’s a reasonable trade-off. Note that this only happens when resizing the terminal; when launching LLDB, the statusline is drawn without clearing the screen. rdar://154778410
This PR ensures we correctly restore the cursor column after resizing the statusline. To ensure we have space for the statusline, we have to emit a newline to move up everything on screen. The newline causes the cursor to move to the start of the next line, which needs to be undone. Normally, we would use escape codes to save & restore the cursor position, but that doesn't work here, as the cursor position may have (purposely) changed. Instead, we move the cursor up one line using an escape code, but we weren't restoring the column. Interestingly, Editline was able to recover from this issue through the LineInfo struct which contains the buffer and the cursor location, which allows us to compute the column. This PR addresses the bug by having Editline "refresh" the cursor position. Fixes #134064
I can't find a proper source for this but many materials say that ANSI rows and columns start at 1 not 0. https://www2.math.upenn.edu/~kazdan/210/computer/ansi.html is as good as I can get: ``` <row> is a number from 1 through 25 that specifies the row to which the cursor is to be moved. <col> is a number from 1 through 80 that specifies the column to which the cursor is to be moved. ``` 0 does work in Windows terminal and Linux terminals, but we might as well be correct and it's one less thing to reason about when auditing this code. From what I read, some terminals correct 0 back to 1 and some treat 0 as a missing argument, which also defaults to 1.
This fixes a data race between the main thread and the default event handler thread. The statusline format option value was protected by a mutex, but it was returned as a pointer, allowing one thread to access it while another was modifying it. Avoid the data race by returning format values by value instead of by pointer.
Make sure the process is stopped when computing the symbol context. Both Adrian and Felipe reported a handful of crashes in GetSymbolContext called from Statusline::Redraw on the default event thread. Given that we're handling a StackFrameSP, it's not clear to me how that could have gotten invalidated, but Jim points out that it doesn't make sense to compute the symbol context for the frame when the process isn't stopped. Depends on #135455
This reverts commit e84a80408523a48d6eaacd795f1615e821ffb233 because on Linux there seems to be a race around GetRunLock. See #134757 for more context.
Make sure the process is stopped when computing the symbol context. Both Adrian and Felipe reported a handful of crashes in GetSymbolContext called from Statusline::Redraw on the default event thread. Given that we're handling a StackFrameSP, it's not clear to me how that could have gotten invalidated, but Jim points out that it doesn't make sense to compute the symbol context for the frame when the process isn't stopped.
This reverts commit 39ace8a63012af7d6ad7bf065c233fd3d5df44a3. while investigating Linux bot failures.