debug: issues displaying dereferenced pointer value in the Variable pane

[ramya-rao-a]

From @willfaught in microsoft/vscode-go#2176:

The dereferenced pointer value is labeled with a single colon, which might be a bug. See the b variable below:

The debugger presentation of the pointer type seems incompatible with the other integral types (variables i and x in the example above). int(0) is displayed as i: 0, X(34) (where X is type X int) is displayed as x: 34, but (*int)(0xc0000160f8) is displayed as p: <*int>(0xc0000160f8). Maybe it makes sense to display it as just p: 0xc0000160f8 and let the user infer the type from the code like for the other variable types (and the presence of the drill down menu)?

Please see microsoft/vscode-go#2176 for more discussion on this

[hyangah]

cc @polinasok

A similar issue was discussed recently in #567 but, there users expressed interest in easier inspection of the dereferenced values. My personal preference is to present the type, pointer value, and dereferenced values (if available) rather than switching to p: 0xc0000160f8 for <*int> in the name of consistency.

I agree the name-less : looks strange.

[polinasok]

@hyangah
+1 that we should not be achieving consistency by stripping useful type information.

The current behavior is consistent with what happens with dlv cli:

(dlv) p myInt
12
(dlv) p &myInt
(*int)(0xc000125e58)

This is also consistent with other compound types that have fields, items or elements, such as arrays, maps, interfaces. Those also show type, not value, at the top and an option to expand into the child elements that build up the value.

A pointer is more than just the raw address because it has an underlying type. And without the type, you can't tell the difference between different kinds of pointers just from the numeric address, but you can tell the difference between ints and floats and such from just the value. Scalar types are inherently different, so they don't have to be consistent. But a case can be made that including extra type information into scalars can be useful as well because then you can differentiate between primitive and user-defined types as well as different flavors of ints or floats. Would it at all be helpful to print ints as "int(5)" vs "myInt(5)" vs "int32(5)"?

@willfaught
: does look strange, but it is not a bug. The lefthand side is for the name of a variable or a field. The data that a pointer points to does not have a name, it's empty, so that is what is printed. I guess to make this less confusing we could add a fake name like <dereferenced>:.... or <value>:....

[willfaught]

The current behavior is consistent with what happens with dlv cli

Interesting, good to know!

A pointer is more than just the raw address because it has an underlying type. And without the type, you can't tell the difference between different kinds of pointers just from the numeric address, but you can tell the difference between ints and floats and such from just the value.

True, but you can't tell the difference between an int(1) and an X(1) (type X int, as above) because they both display as 1.

But a case can be made that including extra type information into scalars can be useful as well because then you can differentiate between primitive and user-defined types as well as different flavors of ints or floats. Would it at all be helpful to print ints as "int(5)" vs "myInt(5)" vs "int32(5)"?

Agreed that "int(5)" vs "myInt(5)" vs "int32(5)" would be more helpful. Perhaps the pointer syntax could be changed from <*bytes.Buffer>(0xc0000160f8) to a more Go-like (*bytes.Buffer)(0xc0000160f8), which would be consistent with them.

I guess to make this less confusing we could add a fake name like :.... or :....

The Go spec defines pointer types with:

A pointer type denotes the set of all pointers to variables of a given type, called the base type of the pointer. The value of an uninitialized pointer is nil.

So perhaps "value" is best.

[polinasok]

Perhaps the pointer syntax could be changed from <*bytes.Buffer>(0xc0000160f8) to a more Go-like (*bytes.Buffer)(0xc0000160f8).

This would require adjusting how all other types are displayed as they all use angular brackets to differentiate types from values visually.

[gopherbot]

Change https://golang.org/cl/252979 mentions this issue: src/debugAdapter: present unreadable values correctly

[polinasok]

We are working on a new version of the adapter (please see dlv-dap.md). It inlines values in place of just the type, so you don't even need to expand to view the data in many cases. I believe this addresses some of the issues described here.