[Lldb-commits] [lldb] [lldb] Store the return SBValueList in the CommandReturnObject (PR #127566)

[via lldb-commits]

jimingham wrote:

> > > * what about commands (I don't know if we have any) whose output consists of more than formatting a single value (which, I guess would be lost if the IDE decides to ignore the output). Are we fine with not supporting that? (we could say that if a command wants to print some extra output, it should use the error stream for that)
> > 
> > 
> > In the longer term, we can also add an optional SBStructuredData for commands that return structured data, like `image lists` or `image lookup` so the UI can print these as tables or something else nice. So if we end up having fancier commands that have both a ValueObject return plus extra annotation, we could add an SBValue type to what an SBStructured data can hold, and have it emit `before` and `after` entries for the extra text.
> > I think that would be better than trying to dump some of the output to stderr.
> 
> That sort of makes sense, but it doesn't sound like you're planning to do that soon, so I'm asking about what should we do until (and if) that happens. The reason I suggested stderr is because that made sense for the commands I'm thinking of. For example, the expression command can produce a result and some warnings and fixit-applied notes. I don't know if these currently go to stderr, but I think it would be okay if they did...

I don't think it's a good idea for commands to put any of their output anywhere but the command result.  Anything that goes to stderr is lost, and particularly if is trying to run their own command loop, so that they are by hand printing the command result, there will be no way to associate that output with the command that produced it.

We don't dump warnings on successful expression evaluation, though we do print fixits.  I would suggest for the near term that if a command that produces a ValueObject returns successfully but with "notes" we should put those notes in the Error object - but still have the state be Success.  That would make sense for the warnings and fixits since Adrian has been working on getting the error output into a structured form to better hold compiler warnings and errors.

https://github.com/llvm/llvm-project/pull/127566