debug: display struct map keys in a more user-friendly way in the debugger

[Gelio]

Is your feature request related to a problem? Please describe.
When displaying the contents of a map whose keys are structs, the keys contain just the name of the struct, as well as the struct's address:

The contents of the key are visible when the row is expanded:

This is already using the new dlv dap adapter in the nightly extension.

While I believe this makes sense for large structs, where the serialized contents of each key would be too long to fit as keys, for smaller structs (such as position here:

type position struct {
	X, Y, Z, W int
}

) that serialize to a relatively short string, we could show the contents directly.

Describe the solution you'd like

For structs that serialize to a relatively short string (e.g. under 50 characters), show the serialized contents of the struct instead of showing the struct name and its address, as in the dlv CLI:

This is related to @polinasok's comment.

Describe alternatives you've considered
I have not really considered other alternatives.

Additional context

Example code sample for which I would expect the keys' content to be shown directly in the debugger:

package main

import "fmt"

type position struct {
	X, Y, Z, W int
}

func main() {
	p := map[position]bool{
		{1, 2, 3, 4}: true,
		{1, 2, 3, 5}: true,
		{1, 2, 3, 6}: true,
	}

	fmt.Println(p)
}

[polinasok]

Thank you for the detailed description. I have looked into this a bit last night. In the new dlv-dap adapter we should be able to reuse some dlv-cli library here to serialize. I just need to figure out how this will work with data structures that are too long. Thanks for the 50 char limit suggestion.

[polinasok]

I made the change that inlined all values in dlv-dap instead of just using types. There is no limit on the length yet. I think this works for all values, but map keys. The values get cut off by the UI partitions, but mousing over them can give you the full thing if needed. But in case of maps, we have key and value side by side, so having the key that's too long will require excessive scrolling to view the value. So truncating them as suggested earlier is clearly desirable. However, in that case, we might end up with two unique keys mapping to the same truncated prefix. So we still need to keep the addresses as the differentiating suffixes for uniqueness. Keys might also end up looking identical because of the value truncation due to partial variable loading. Here is an example:

Update 4/15: vscode now fixed de-duping (microsoft/vscode#107506), so even with identical prefixes post-truncation we will not loose any entries.

[polinasok]

@Gelio I will add char limit as you suggested next. This might result in keys that look identical. I was able to get the attention of vscode devs to change vscode not to drop duplicate keys (microsoft/vscode#107506). With that in mind do you have an opinion on keeping or removing he address suffix as the differentiator?

For example, if we were to truncate the keys in our position example:

main.position{X: 1, Y: 2, Z: 3...: true
main.position{X: 1, Y: 2, Z: 3...: true

vs

main.position{X: 1, Y: 2, Z: 3... @0x1234567: true
main.position{X: 1, Y: 2, Z: 3... @0x7654327: true

[Gelio]

@polinasok That's awesome! Thanks for putting in the work 🎉

Well, now that I think about it, adding the addresses would probably be less confusing, as it clearly shows that even though 2 keys have the same prefix, they are in fact different objects. It's not a strong opinion, but I reckon that would be the safer bet here

[polinasok]

This has been fixed in dlv-dap.

[Gelio]

Great, thank you!