x/tools/gopls: 'references' on embedded field returns refs only to field, not type

[adonovan]

The form struct {T} is unique in the Go grammar in that the identifier T is both a reference (to a type) and a declaration (of a field). When gopls responds to a references query on the identifier, it chooses arbitrarily to the interpret it as a field, and does not report references to the type. I think it should report the union of both.

[muirdm]

If the embedded type is popular (e.g. "bytes.Buffer"), you could lose the field references in the sea of type references. Maybe we can keep the field references before type references in the results? Or is there some other way for the LSP client to distinguish them?

[adonovan]

That's a good point. There's a related situation in renaming where an embedded field couples a field and a type: renaming a reference to the the type must of course rename the field, but renaming a reference to the field probably shouldn't rename the type as well. So, the renaming tool gives an error hinting that, if the bigger renaming was intended, it should be initiated on a reference to the type. But I don't see any way that 'references' can return a hint along with the smaller result. Ordering field refs before type refs is all we can hope for; or leaving things as they are.

[muirdm]

any way that 'references' can return a hint along with the smaller result

Could gopls issue a notification or whatever that shows up for the user?

[adonovan]

Good question. We should experiment.

[findleyr]

Ordering field refs before type refs is all we can hope for; or leaving things as they are.

I'm not sure if all clients preserve the ordering of references, though I think most do.
I do think that this is inconsistent behavior, but probably not a high priority.