[Lldb-commits] [lldb] [lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (PR #77026)

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Wed Jan 10 00:11:08 PST 2024


clayborg wrote:

> > Looks fine to me. Can we add a test?
> 
> Updated the existing tests to check the adjusted format.
> 
> One issue I did notice with tests is that the response to an expression will include a response are automatically persisted by `SBValue::GetDescription()`, so you will see the value name in the response, for example:
> 
> ```swift
> // Example swift struct.
> struct Event: Identifiable, Comparable {
>   let id: String
>   let name: String
>   let time: DateInterval
>   var count = 0
> }
> ```
> 
> ```
> > self
> (Calendar.Event) $R1 = {
>   id = "e1"
>   name = "Event 1"
>   time = (start = 2024-01-03 17:00:00 UTC, duration = Swift.Double @ 0x0000600001754928)
>   count = (_value = 0)
> }
> > self
> (Calendar.Event) $R2 = {
>   id = "e1"
>   name = "Event 1"
>   time = (start = 2024-01-03 17:00:00 UTC, duration = Swift.Double @ 0x0000600001754928)
>   count = (_value = 0)
> }
> > $R2.count + 2
> 2
> ```

Ah, this looks like swift's description generator actually prints out `(_value = 0)` when it is part of a larger struct that has a description. Nothing you can do about this.

My main concern is that the SBValue::GetDescription() can create multi-line output, and as you have discovered, when displayed in the GUI, it will chop off the value at the first newline which makes this less useful. I am not sure how I feel about this as this description could be quite large and it isn't doing much better than what used to be there before with the `<typename> @ address` description, now we will get `(PointType) pt= {` which isn't much better.

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


More information about the lldb-commits mailing list