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.
.swiftinterface files into the dSYM bundle. These typically come only from the SDK (since textual interfaces require library evolution) and thus are a waste of space to copy into the bundle. The information about this is being parsed out of the control block, which means duplicating 5 constants from the Swift frontend. If a file cannot be parsed, dsymutil errs on the side of copying the file anyway. rdar://138186524
When you run lldb without colors (`-X`), the status line looks weird because it doesn't have a background. You end up with what appears to be floating text at the bottom of your terminal. This patch changes the statusline to use the reverse video effect, even when colors are off. The effect doesn't introduce any new colors and just inverts the foreground and background color. I considered an alternative approach which changes the behavior of the `-X` option, so that turning off colors doesn't prevent emitting non-color related control characters such as bold, underline, and reverse video. I decided to go with this more targeted fix as (1) nobody is asking for this more general change and (2) it introduces significant complexity to plumb this through using a setting and driver flag so that it can be disabled when running the tests. Fixes #134112.