[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)
Adrian Prantl via lldb-commits
lldb-commits at lists.llvm.org
Wed Sep 25 17:57:04 PDT 2024
adrian-prantl wrote:
> > > This seems like it could be problematic for IDEs, if they don't print the error in the same window as the expression being evaluated. The arrows could end up pointing to nowhere, or to the wrong place in the expression (if we don't get the right offset).
> >
> >
> > Eventually I want IDEs to get access to the same kind of machine-readable diagnostics, so they can format errors however they like (or, if they aren't interested, dump the pre-rendered textual error that is still available).
>
> I'm still worried about this. Yes, the IDEs can dump the pre-rendered error (and right now, that's all they can do), but this rendering assumes that the error message will be printed in a particular way (right under the original command, which will include the prompt and everything). I think that's fine for the commands entered through the LLDB command line, but I don't think it's reasonable to expect that every caller of `SBCommandInterpreter::HandleCommand` will do the same thing. I've looked at what lldb-dap does, and it looks like it will mostly be okay, because it explicitly echoes the command to be executed (although it [hardcodes the prompt string](https://github.com/llvm/llvm-project/blob/60ed2361c0917b4f8d54cb85935cfbf8904aa51d/lldb/tools/lldb-dap/LLDBUtils.cpp#L61) instead of getting it from lldb), but if you're looking for a example, you don't need to look further than your test case. Even though you've formatted the test input nicely, this is how its trace looks like when you run it:
>
> ```
> Ran command:
> "expr -i 0 -o 0 -- a"
>
> Got output:
> ^
> ╰─ error: use of undeclared identifier 'a'
> ```
>
> (sure we can fix this so that the output makes sense, but I wonder how many other such callers are out there)
Just to explain my motivation., in the end what I'm most interested in is exposing the machine-readable diagnostics through the SBAPI, so that is where this is going next.
I'm actually surprised that lldb-dap sees the new diagnostics because I thought it would run the expression through a lower-level API like SBFrame::EvaluateExpression(). But I guess it just provides a "terminal" window that passes everything through HandleCommand. To support this better, I'm thinking about adding a setting to opt into the inline diagnostics that only `lldb` sets, so we don't get unexpected results like this.
https://github.com/llvm/llvm-project/pull/106470
More information about the lldb-commits
mailing list