Redundant package prefix in anonymous struct field name

[nd]

trafficstars

1. What version of Delve are you using (dlv version)?

built on commit ac3b1c7

2. What version of Go are you using? (go version)?

go version go1.12 linux/amd64

3. What operating system and processor architecture are you using?

linux/amd64

4. What did you do?

Printed the value of the t variable once the program reached a breakpoint:

package main

import "runtime"

func main() {
	t := struct {a string} {a: "ok"}
	runtime.Breakpoint()
	println(t.a)
}

5. What did you expect to see?

It's type presented like this struct { a string }

6. What did you see instead?

It's type presented like this struct { main.a string }

Notice the redundant package name prefix in the field.

Rpc log:

(dlv) p t
DEBU[0005] <- RPCServer.Eval(rpc2.EvalIn{"Scope":{"GoroutineID":-1,"Frame":0,"DeferredCall":0},"Expr":"t","Cfg":{"FollowPointers":true,"MaxVariableRecurse":1,"MaxStringLen":64,"MaxArrayValues":64,"MaxStructFields":-1}})  layer=rpc
DEBU[0005] -> *rpc2.EvalOut{"Variable":{"name":"t","addr":824634001256,"onlyAddr":false,"type":"struct { main.a string }","realType":"struct { main.a string }","flags":0,"kind":25,"value":"","len":1,"cap":0,"children":[{"name":"a","addr":824634001256,"onlyAddr":false,"type":"string","realType":"string","flags":0,"kind":24,"value":"ok","len":2,"cap":0,"children":[],"base":4678956,"unreadable":"","LocationExpr":"","DeclLine":0}],"base":0,"unreadable":"","LocationExpr":"[block] DW_OP_fbreg -0x30 ","DeclLine":6}} error: ""  layer=rpc
struct { main.a string } {a: "ok"}

[aarzilli]

This is complicated. We're just printing the name of the type that's in debug_info, to remove those prefixes we'd have to parse that string and strip them. Unfortunately there's no parser for that (it looks like go, but it isn't valid go, obviously) and no formal grammar (besides the code that outputs them, somewhere in the compiler). The name in debug_info comes from the name of the type symbol produced by the compiler, we can't change the way the compiler generates that name because it probably has a good reason to include that prefix (or maybe not? I don't know for sure). We could regenerate the name in the linker when debug_info is written but that's probably expensive and complex. Parsing and stripping them in the debugger is probably the least-wrong answer, but I'm not sure we want all that extra complexity for a cosmetic improvement.