make the ambigious locspec smarter

[stevenhay]

The most annoying thing about dlv is this:

$ (dlv) list MyFunction
Command failed: Location "MyFunction" ambigious: package/myType.MyFunction, package/(*myType).MyFunction

Okay, so I'll try make it clearer

$ (dlv) list myType.MyFunction
Command failed: Location "myType.MyFunction" ambigious: package/myType.MyFunction, package/(*myType).MyFunction

At this point it's really not ambigious, is it? If I wanted the pointer version I would have specified (*myType).MyFunction, but whatever, I'll add part of the package name

$ (dlv) list pkgpart.myType.MyFunction
Command failed: Location "pkgpart.myType.MyFunction" ambigious: package/myType.MyFunction, package/(*myType).MyFunction

... really? Again, I would have specified pkgpart.(*myType).MyFunction if I wanted the pointer version, it is not ambigious.

If my package looks like: github.com/account/project/some/package/folders/file.go I really don't want to have to type that in every single time I want for a locspec, especially since that pointer value is only even present because it's implementing an interface, there's not even project code.

Furthermore, how does this fail due to being ambigious? Clearly the pointer version is specified.

$ (dlv) list pkgpart.(*myType).MyFunction

In fact, unless I provide the complete path it always complains about being ambigious even when the rest of the path is the same for both options. Given the function with and without the pointer receiver is within the same file, the entire path is the same,

dlv 1.22.0

[aarzilli]

It isn't possible to define a method with the same name but with both a pointer and a non-pointer receiver: https://go.dev/play/p/U4O8V1rMx_k

[stevenhay]

Hey! Yeah that's why it's even more annoying. It's not me that's defining the pointer version. The compiler automatically generates that stub when you implement an interface with a non-pointer receiver. I believe (could be wrong here) but it's because both T and *T implement the interface since *T inherits the method sets of T.

https://go.dev/play/p/O7lL6lpyeug

edit: this is what dlv will output for the above code

(dlv) list MyFunction
Command failed: Location "MyFunction" ambiguous: main.myType.MyFunction, main.(*myType).MyFunction…
(dlv) list myType.MyFunction
Command failed: Location "myType.MyFunction" ambiguous: main.(*myType).MyFunction, main.myType.MyFunction…
(dlv) list main.myType.MyFunction
Showing C:/Users/Stevie/Documents/tmp/main.go:11 (PC: 0x1092fe4)
     6:         MyFunction() string
     7: }
     8:
     9: type myType struct{}
    10:
    11: func (myType) MyFunction() string {
    12:         return "hello"
    13: }
    14:
    15: func Foo(i myInterface) {
    16:         fmt.Println(i.MyFunction())
(dlv)

If the implementation of MyFunction is declared directly as a pointer receiver (func (*myType) MyFunction() string) then this issue doesn't arise:

(dlv) list MyFunction
Showing C:/Users/Stevie/Documents/tmp/main.go:11 (PC: 0xe92fe4)
     6:         MyFunction() string
     7: }
     8:
     9: type myType struct{}
    10:
    11: func (*myType) MyFunction() string {
    12:         return "hello"
    13: }
    14:
    15: func Foo(i myInterface) {
    16:         fmt.Println(i.MyFunction())
(dlv)

[aarzilli]

Ah, yes, it's because you are calling it through an interface. This is unfortunate, however I'm not sure there's anything we could do about this.
Pointer receivers are far more common in Go than non-pointer receivers, so it made sense to make them easier to specify, hence pkg.atype.afunc being able to refer to pkg.(*atype).afunc. This can not be changed because it would be backwards incompatible.

[stevenhay]

Ahh, I see, I'll just define my methods as pointer receivers instead. Thank you anyway!