labath 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 that, 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) https://github.com/llvm/llvm-project/pull/106470 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
