Thanks! I imagine this is straightforward to fix.

High level notes:

• Add a new kindInterface here: https://cs.opensource.google/go/x/tools/+/master:gopls/internal/golang/completion/printf.go;l=155;drc=6823da4bc3f39c895ac7f0a46d3994d146397193
• Update completion.candKind to recognize interfaces
• Write tests, e.g. at https://cs.opensource.google/go/x/tools/+/master:gopls/internal/test/marker/testdata/completion/type_mods.txt

Adding to the next milestone.

I will work on this issue

Thanks @naeemaei! Let us know if you need any additional guidance.

* Update `completion.candKind` to recognize interfaces

Maps, channels, unsafe.Pointer, and functions as well. Anything pointer-esque, really. Also, interfaces are probably a special case separate from that and not really limited to %p: if the static type is an interface, then the dynamic type might be valid for any verb.

I added the kindInterface to the parsePrintfVerb function and also handled the kindInterface in completion.candKind then the line completes without & when using local self-build gopls.

But when I print an interface variable, the print output is as below:

structInterface = person{FirstName: "name"}
fmt.Printf("structInterface: %p\n", structInterface) // structInterface: %!p(main.person={name})
fmt.Printf("structInterface pointer: %p\n", &structInterface) // structInterface pointer: 0xc000014070

When the interface underlying type is a pointer output is the underlying variable address:

strct := &person{FirstName: "name"}
structInterface = strct
fmt.Printf("struct pointer: %p\n", strict) // 0xc000014090
fmt.Printf("structInterface: %p\n", structInterface) // structInterface: 0xc000014090
fmt.Printf("structInterface pointer: %p\n", &structInterface) // structInterface pointer: 0xc000014070

if the static type is an interface, then the dynamic type might be valid for any verb.

This part is a bit vague, I need your guidance regarding the specific logic that should be handled after recognizing interfaces in completion.candKind
@findleyr
@dominikh

@naeemaei I think the point is that when the argument is an interface, we don't generally know whether or not it holds a pointer (or any other kind of type). In the absence of certainty, it is better not to apply the &. We should only apply type modifiers when they are strictly required to have a valid type.

So it sounds like gopls is working as intended in your example.